Carbon版HyperCardを騙ろう - 1067262136

1：ぷご：2003/10/27(月) 22:42: Xcode+CarbonでOSX用のHyperCardを作ってしまえ！
という構想はあるものの、そこまでの能力と時間と資金は
ありません。というわけで、構想や妄想や感想や暴走を
繰り広げてみようというスレッドです。

いけそうだと思ったら本気で作るかも。
2：ぷご：2003/10/27(月) 22:54: Q.なぜにXcode？
A.無償、最新、Carbon対応だから

Q.Cocoaはどうした？
A.ObjectiveCでは移植が困難になるため。純粋なCを使う。

Q.移植というのはWindowsへの移植？
A.それも含めて、Palm、UNIX、Classicなども考えられる。
　選択肢は多い方がいい。

Q.本気？
A.考える事自体が面白い。それに考えるだけでも意義はあると思う。
　今できなくても、将来できるかもしれない。
3：ぷご：2003/10/28(火) 22:48: ●基本設計
本体は中間言語インタープリタとして動作する。
HyperTalk風言語を中間言語にコンバート。（スクリプト保存時に行う）
変数には数値（double型）と文字列を格納できる。
テキスト、画像、サウンド、ウィンドウ、メニュー、ファイルなどを扱える。
本体そのものはGUIを持たない。GUIは中間言語とリソースで作る。

中間言語にすることで高速性、柔軟性、移植性、拡張性などバランスのとれた
ものにできる。C言語に匹敵するほどの速度は必要ない。
4：ぷご：2003/10/28(火) 22:57: ●過去との互換性
HyperTalkをベースにした言語を使えるようにする。
HyperTalkから簡単に変換できる程度のもの。

カードピクチャやボタン、フィールドのデータやプロパティは
コンバート用のHyperCardスタックを作ってリソースに書き出す。
どのような構造になっているのかはXMLあたりで記述したいなぁ。
5：ぷご：2003/10/28(火) 23:02: ●ペイントを基本に
MacOSXではアンチエイリアスが多用されており、
これと相性のいいのはドロー形式なのだろうが、
ペイントの方が分かりやすいため、あえてペイントを
基本にしてデザインできるようにする。

液晶の解像度が今後大きく上がるのではないか？
そのとき、アンチエイリアスは不必要になるだろうと
考えている。僕個人としてはそうなってほしい。
6：ぷご：2003/10/28(火) 23:10: ●フィールド
テキスト編集機能をどう実現すればいいのかは悩むところ。
表示だけならHTMLを表示するのが良さそう。
Webをそのまま表示できれば便利だし、案外楽に組み込めそうに思う。

でも、やはり普通にMLTEを使うべきかな。
なるべく自前での実装はさけたい。
7：ぷご：2003/10/28(火) 23:14: ●アプリケーション化
スタックデータはすべてリソースに持つことになるので、
アプリケーション化といっても特別なことをする必要は
あまりなく、リソースを組み込むくらいで良い。

ちなみに、１アプリケーションで複数のスタックを開くことはできない。
１アプリで１スタックに対応させる。
8：ぷご：2003/10/28(火) 23:23: ●開発方法
いわゆる「オープンソース」の開発では、
開発者自身の興味や技術的な面にばかり
力が入ってしまう傾向があるように思われる。
HyperCardにはそれは似合わない。

ビルアトキンソンは何を考えながらHyperCardを
作ったのだろうか？

ベース部分は一人で作らないといけないだろうと思う。
9：ぷご：2003/10/29(水) 19:48: 昨日分を修正
・スクリプトは保存時コンパイルではなく、実行時コンパイルとする
・複数のスタックを同時に開くことはできないが、ライブラリ化は可能。
　リソースとスタックスクリプトを扱える。
10：ぷご：2003/10/30(木) 23:26: HyperCardでは視覚効果は大したことはできなかったが、
いまのCPUではかなりのことが可能。ページめくりくらい欲しい。

カードだけでなく、ボタンやフィールドの表示/非表示でも
視覚効果を付けることができる、のは作るの大変そう。
11：ぷご：2003/11/01(土) 15:24: 中間言語はBASIC的なものになると思うんだが、
それではあまり良くない。魅力に欠ける。
とは言っても速度面とシンプルさ、分かりやすさの
バランスが必要なので凝った事は出来ないしなー。

GOTO文はさすがに作りたくないので入れませんが。
ifとrepeat、next repeat、exit repeatでできるでしょ。
12：ぷご：2003/11/01(土) 15:50: プロジェクトは名前が重要だと思ってみたりする。
mirageとかいうXCMDはその名の通り蜃気楼のように消え去った。

というわけで、現在の案
中間言語実行アプリ：「MacRoke」（まっくろけ）
中間言語：「未定」
高級言語：「未定」
RAD型開発環境：「未定」

未定だらけだ。
13：ぷご：2003/11/01(土) 20:08: mallocとfreeで文字列変数を確保しようと思っていたのだが、
Poolを作って1024byte単位で確保とかしたほうが良さそう。
メモリの断片化&メモリの再確保による速度低下を防ぐわけ。
14：ぷご：2003/11/01(土) 21:26: 変数名から変数の中身を取得する部分や、
関数名から関数の内容（スクリプトだから単なるテキスト）を
取得する部分はリストの単純サーチで作ればいいと思っていたのだが、
速度低下が激しい気がする。

静的リンクは無理としても、せめて１度参照したものだけでも
静的リンクに出来ないものか？

いや、あまり変な実装するのはやめておこう。
最初は出来るだけ単純な構造で作り上げ、その後
パフォーマンスが悪いところを集中的に改善するほうが
良い結果が得られる。最もシンプルでデバッグしやすい作戦でいこう。
15：ぷご：2003/11/01(土) 23:16: リソースをいろいろ扱えるようにしたい。
Carbon版のResEditが作れるくらい。

それができれば、それだけでも存在価値はありそう。
スクリプティング可能なリソースエディタだなんて！
16：ぷご：2003/11/02(日) 01:43: ゲームを作る事はあまり考えないようにする。
ゲームを作れるだけのポテンシャルを持つ基盤にしなければ
ならないが、ゲーム以外が作れないなら意味が無い。

教育分野で使える、とすれば魅力なんだが使われるとも思えないし、
便利ツールが作れる、プロトタイプが作れる、というところで
適当に落ち着かせよう。高度な開発環境ならXcodeがある。
便利な開発環境が足りないんだ。
17：ぷご：2003/11/02(日) 10:57: Mac&Win両対応ってのはもう古い。
ユーザ数を最大にしたければ、
「Win専用」
でいいじゃないか。

MacとWinじゃ思想が違うので、出来上がるものも
違ってくるんだよ。だからMacでしかできないものを
作るべきなんだ。Winに移植するためには異常な労力が
掛かるべきなんだ・・・。

とは言いつつも、できるだけ移植しやすいように作ろうとか考えているぷごであった。
18：ぷご：2003/11/02(日) 12:46: こういうソフトは、フリーでなければならない。
個人では開発力が足りない。
オープンソースでは方向性が違ってしまう。

方向性を固めてから、オープンソースというのが一番現実的かな。
19：ぷご：2003/11/05(水) 23:23: emacsみたいにスクリプト内蔵？のスクリプトエディタに出来ないか考えてみる。
スクリプトエディタ内でスクリプトを使うというのも面白いかも。
しかし、そもそもスクリプトエディタそのものをスクリプトを使って作ろうと
思っているので、元々の構想通りなのだった。

ウィンドウを複数開けるが、メインウィンドウは１枚のみ。
テキストカーソルはサブウィンドウにも置ける。
メッセージボックスやスクリプトエディタはサブウィンドウとして実現。
リソースエディタやパレット、デバッグログ表示もサブウィンドウ。
20：ぷご：2003/11/07(金) 00:58: GIMPみたいにスクリプトを内蔵した画像処理ソフトを、、、
って、マクロやAppleScriptのほうが便利だな。

テキストエディタの場合は出来る限りキーボードから
マウスに持ち替えなくても操作できるようになるのが理想的。

とはいえ、GUIではマウスを使う場面は多くなる。
HyperCardのようにキーボードショートカットを充実させたいところ。
21：ぷご：2003/11/10(月) 22:06: 中間言語レベルでも計算式の評価くらいできるようになっていないと
不便だし、速度もかなり遅そうだ。

逆に言えば、計算式の評価さえあればそこそこ使えそうな気もする。
基本コマンド：AAA bbb,ccc
同じコマンドを呼ぶ別方法（AAAが記号以外のとき）：AAA(bbb,ccc)
さらに別方法（AAAが記号で引数が２つのときに限る）：bbbAAAccc
これでいけるかな