アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
ユーザーライブラリ (スコア:1)
QtからX依存の部分を切り離したもので、Unicode扱えるQStringクラスとかそれはまぁ色々なものが着いて来るんですが。
#暇になったらやってみよっかなぁ。
Re:ユーザーライブラリ (スコア:1)
ごっそり無いような気がしますが、誤読でしょうか？
UIとかの部分が無いと、純粋にコンパイラでコンパイルできるかどうか
というだけの問題になっちゃったりするんで、
「乗らんかな」という興味の対象には、なりにくいかも、と
ふと思ったのですが。
＃まあFileアクセスとかも充分にOSアーキテクチャ依存なテーマだけど。
それにしても、そっか。
C++で独自アーキテクチャなOSってことは、
libc(ってんだったよね)とも無縁なわけですね。
＃従来(?)と全然違うアーキテクチャのGUIを構築したい今日このごろなのでG7
＃Widgetが「Displayに」描画するんじゃなく、
＃Widgetが「親Widgetに」描画するっていうモデル。
＃イベントも「親Widgetから」渡されるってモデル。
＃Widgetの親子関係(親子間のデータのやりとり)だけで出来るだけ全ての事柄が動くようなモデル。
＃そうすれば「GUI版のExpect」や「マルチマウス」も無理なく対応できるはずなので…
Re:ユーザーライブラリ (スコア:1)
ただ便利なクラスが色々有るので動いたらよいかなと。
これが動くとKHTMLなんかも動いたりしますので。(もちろん描画部分だけはMona用に実装しなければいけませんが、HTML、CSS、Javascriptの解析部分等はTinyQtに含まれているクラスのみで動くので)
「乗る」というとちょっと誤解が有りますね。すいませんでした。
Re:ユーザーライブラリ (スコア:0)
> ごっそり無いような気がしますが、誤読でしょうか？
2chのスレの281 [2ch.net]のことですか？
それであれば誤読です。
X上のBochsでMonaを動かそうとしたときの話です。
MonaでXを動かそうとしているわけではありません。
> UIとかの部分が無いと、純粋にコンパイラでコンパイルできるかどうか
> というだけの問題になっちゃったりするんで、
> 「乗らんかな」という興味の対象には、なりにくいかも、と
> ふと思ったのですが。
何をコンパイラでコンパイルするのですか？
> C++で独自アーキテクチャなOSってことは、
> libc(ってんだったよね)とも無縁なわけですね。
基本
Re:ユーザーライブラリ (スコア:1)
>何をコンパイラでコンパイルするのですか？
他の方が書いてくださいましたが、TinyQtのほうの話でしたので、
コンパイルの対象もTinyQtです。
あ。サイトを見たところ、名称が違いますね。 TinyQ。最後のtは要らない。
＃何が削除されてることを意味するんだろうか？(^^;
>基本的にはそうなのですが、最低限のlibcは実装しようとしている [osdn.jp]ようです。
なるほど。
ところで蛇足、相変わらずよく判ってないんですが(^^;プロセス起動はforkとは違うやりかた、ですよね？ [osdn.jp]
(だったら)わーい。
Re:ユーザーライブラリ (スコア:1)
>固定委譲にどんな意味があるのでしょうか？
時間軸については「固定」したいわけではないです。
つまりWidgetの生成後の、(Widgetの親子関係の)付け替えは、幾らでも許すっていう奴。
ここらへんはSqueakとかと同じ(ですよね)。
Squeakの場合、マウスポインタすら1つのWidgetで、
DragDropのDrag開始は対象Widgetが「元の親からマウスポインタWidgetに乗り換えた」という形で表現されてるそうで、
従来のGUIと比べての余りのシンプルさに唖然としてしまった次第。
これからはせめてこれくらいは出来ないと駄目ですね。
あと、ビジュアルと委譲関係を一致させる(そういう意味では固定ですね)っていう発想をしていますが、
それは「わかりやすさ」を狙ったせいです。
というのは、ビジュアルプログラミング(^^;とかの方向性をやりたいんで。
ユーザ(しばしばトーシロ)でも、弄れば弄ったなりのモノになる、という感じの。
なので、良くも悪くも見たまんまに動く(orしばしば動かない(藁))といいなぁと。Program自体のWYSIWYG化。
触ったことないけどIntelligentPadとかが似た方向性なのかなあ？？？
効率とかはあまり優先したくありません。
ちょうど動作効率より記述効率のScript言語が最近元気なように、
GUIも記述(変更)のしやすさを優先するほうに倒しても良い時期じゃないかと。
＃他人が作った(Swingの)ソフトで「どのWidgetがProgramの何処に」通じているのかを探るのが物凄くシンドくて参ったので、G7
あと、ビジュアルと一致した委譲はあくまで「主な委譲先」の話です。
面倒な手段(=とりあえず思い描いているのは古典的なProgramming)を使えば
それ以外の委譲も出来ないわけじゃない、くらいの世界を考えました。
で、使いたくない人は使わなければいい、と。
ただ、主な委譲だけで記述できる範囲は、それなりに広くできるといいなぁとは勿論思っています。
そういう意味で「できるだけ」です。
>しかしWinFXでは任意のオブジェクトに委譲できるようなモデルに移行するので、
ああ。WinFXって、次世代Windows(ってのか)の事なんですね。
ええと。「動的委譲」というのが実際どういうものなのかは知らないんですが、
こういう話だと、どれくらいすれ違って(^^;いるんでしょうか？
＃そこはかとなくググってみましたが旨く発見できず。
ただ、OSとかが用意するWidgetの仕組みは、もうどうでもいいような気がしています。
というのは、自在な委譲を極めようと思ったら今でも既に簡単に出来るわけでして、
つまり我々がプログラミングすればいいんです(^^;。ええと、こういう問題でしょうか？
一緒になるかどうか判りませんが、古い体験でいえば、VC++とDelphiの差を連想しました。
つまり、WindowsのWidgetに対する「巧妙なラッパー」としてDelphiのオブジェクト群は設計されてて、
生Widgetの色々な使いにくさを隠蔽してくれる、っていうアレ。
(ちなみに、逆にDelphiで腹が立ったのは、単なる「Line」のWidgetすら無かったという点。)
で、一方、なまじ自在な委譲をやってくれると、今度は
他人(に限りませんが)のプログラムが「読みにくい」という問題が生じるような
気がしています。
あまり上手じゃないやりかたで、自由度ばかり増えてしまったので、
いわば「GUIスパゲティ」「イベント委譲スパゲティ」に陥っているんじゃないかと。
それを解決する道の1つとして、今のところ個人的には、
「何処に何が(何と何が)繋がっているか」が、もろに「見える」という
プログラミングスタイルが実現されると、良いんじゃないか？と思っているところなんです。
＃このGUIモデルのほかに「配線モデル」も考えてます。
＃ただ、よりスパゲティになりにくい(笑)のは、線よりも面かなーと。
ただ、自由度は落ちますね。そういう意味では高機能にはしにくいかも。
Re:ユーザーライブラリ (スコア:0)
Re:ユーザーライブラリ (スコア:0)
ごめんなさい。ご指摘の通りでした。