k3c 曰く、 "VIMのWebページで紹介されていたのですが、先日/.Jでも話題になったGNOME上で動くXimian製Outlookクローン、Evolutionのメール編集ウインドウにVIMを使う（スクリーンショット）というすげーツール、その名もGnome-vimなるものが開発されています。GtkHTMLのインターフェイス部分を乗っ取るらしいのですが…そこまでやりますか…いやはや…。"
bonoboではなく？ (スコア:3, 興味深い)
え？MSのOLEだかなんだかに似たプロセス(というよりObject)やりとりの仕組み…
たしかBONOBOとかいったよね…を使ってどうこう、というものではなく、
本当に力任せに乗っ取った、んですか？
もしそうなら、別の意味で凄いなあ。
あるいは、乗っ取りをやらせるクラス(っていうんでしたよね＞GnomeつーかGtk)を
作ったとかなら、更に違う意味で凄いですが。
その乗っ取り機構を、今回のアプリに興味ない人々も、共有できますからね。素晴らしいことです。
あ。すみません。最近あっちの分野がどうなってるか全然見てないんで、
今は Unix をもう少しマシなものにしよう [os-omicron.org] の筋書き(?)とは全然違う世情になっているんでしたら、御免なさい。
#てゆーかBONOBO自体触ったこともないですm(__)m
ええと。うだうだ言うより、原文を読もうっと。
>Gnome-vim is a Bonobo component which embeds VIM and implements (part of) the same interface as the GtkHTML component.
ふむ。これは「乗っ取る」という下品(笑)なことではなく、OOPでいう「多態」でしょうね。
#bonoboは元気だったようですね。よきかなよきかな。
GtkHTMLの兄弟クラス、または動的に同じInterfaceを持つクラス
(ええと、BONOBOは動的なInterfaceでしたっけ…)、っていう奴。
ここでのimplementsという単語は、javaなんかでお馴染みのアレと全く同じ概念を指しているはずです。
「乗っ取っては」いないんで「共存」だって出来る、はずですよね。
2枚のエディタ画面を立ち上げて(このアプリにそれが出来るならですが。
というかそういうアプリを好きなだけ作ればいいですし)、
一方は従来どおり、他方はvim、って同時存在させることも可能なんだろうなと。
コンポーネント指向万歳、ということで。
>Gnome-vim uses the zvt widget (terminal), and runs a copy of vim inside of that.
vimプロセスをterminalの中で立ち上げて、Gtkの普通のイベントをviのキーストロークコマンドに
すりかえている、ってこと？
ということは子プロセスで普通のvimは上がっているのかな？
こりゃ好きなversionのvimが使えるかな？
というかこの原理だと、イベントすり替え部分を修正(もとい多態?)するだけで、
Emacsだろうがなんだろうがイケそうな。
Emacsだとデカすぎていちいち立ち上げたくないかな。まぁEmacsClientなるものが
世の中には有ると聞いたんで、こういう場面でこそそういうのを使えばいいのかも。
#偶然だけど同様の原理で起動した子プロセスの外観をがらっとすげ替えるシステムを俺も今作ってる。エディタと全然関係ない分野だけど。
あ。待てよ。「copy of vim」って書いてあるなあ。
もしかして違うか？
このコンポーネント自体がvimの実装をコピったものを持っているんだろうか？
ところで話は飛ぶが、
こういう「コンポーネント」において、GPLというライセンスの伝染性は、どこまで波及するんだろ？
コンポーネントそれ自体が、アプリケーションのようでもあり、ライブラリのようでもあり、なんだけど。
Re:bonoboではなく？ (スコア:2)
私もあまり英語は得意じゃないんだけど、コンパイルするときに使いたいvimのpathを指定するようになっているので、内部ではvimそのものを使うようです。
このコンポーネントがkeystrokeを、内部に起動しているvimに送って、出力をコンポーネントに表示する模様。
GTK+ってことは、Sylpheedのエディタをvimにすることも可能なのかな？
gvimじゃないのかぁ。 (スコア:2)
それじゃあ、gvimのメニューをメールエディタのメニューに統合したりとかは出来ないな。
アプローチとしては一番楽な方法なんだろうけど、ちょっとさびしい。
しかし、エディタがGtkHTMLっていうのにはちょっと違和感。
-- Che Che - Bye Bye
Re:gvimじゃないのかぁ。 (スコア:1)
すみません。俺は最初にショットを見たとき、
「最近のgvimは、上のほうにCC:なんていう入力欄を表示できるのかな？」
などという見当違いのことを一瞬考えてしまいました(笑)。
本文書き欄そのもの(だけ)がvimなんですものね。
#そーゆーのはdelphiで慣れてるんじゃなかったのか俺？
>アプローチとしては一番楽な方法なんだろうけど、ちょっとさびしい。
どっちかってーと俺も書いたように、「お好きなエディタを使えますぜ」的な
ソリューション(死語?)に向いたやり方かなーと。
>エディタがGtkHTMLっていうのにはちょっと違和感。
該当メーラーのエディタ部分「が」そのクラスだったんで、今回もそれに合わせた、
ってことだったりするでしょうか？
なんせアウトルックとかいうアレのCloneなんですよね。
後々皆が協力(^^;しやすい形に整理するとしたら、ラッパーをもう一段かます、
とかするとしあわせになるかも。
(Gtkの構成は知らないんで的外れかもですが)外部エディタ呼びクラスをまず作り、
それの派生として好きなエディタをぶらさげる奴を作り、
一方でエディタクラスとHTMLクラスのそれぞれの兄弟として
エディタ呼びObjectを接続できる口を持った奴を作る。
そうすりゃ好きなエディタがGtk上の普通(?)エディタにもHTML云々にも
がちゃっと一発で接続可能になる、かなーー。
Re:gvimじゃないのかぁ。 (スコア:2)
エディタのパスと、コマンドのキーストロークを定義した設定ファイルを読み込むようにしてやるとemacsだろうが、jedだろうが使えるようにできそう。
手っ取り早くエディタを選ぶコンポーネントを作るっていう用途にはいい手法でしょうね。
ただ、どこでエディタを選ぶ機能を作るのかっていう点ではBonoboのようなコンポーネントときれいにかみ合わせることができるのかな。
選択用ダイアログとかをどこに作るべきか。
どうやらそのようです。
GtkHTML [gnu.org]自体がHTML renderer and editorというコンポーネントみたいですね。
なぜか、すっきりしませんが、OE cloneということで、何と無く分かるような気もする。
-- Che Che - Bye Bye
Re:gvimじゃないのかぁ。 (スコア:1)
>選択用ダイアログとかをどこに作るべきか
これまたGtkの事情を知らないんで、delphiならこうするって話でお茶濁させて頂きます(^^;が、
#Gladeとかいうのがそれなのかな? http://staff.aist.go.jp/t.kato/program/gtk/glade.html
RADなGUI画面作成環境で、component(の雛型instance)をマウスでほいほい編集するときの話なんですが、
ほいほい「やられる(編集される)」のがcomponentであり、
一方でほいほい「やる(編集する、orその手伝いをする)」のが
ComponentEditorとかPropertyEditorとかいうクラスだったりします。
PropertyEditorが特に重要かな。ObjectInspector(PropertyWindow)の中の項目1つづつを
どう編集するか?を司るクラスです。型ごと&componentごとに作ります(使いまわし可)。
intとかのありがちな型のためのEditorクラスは定義済みだし、
#集合型や範囲型のも有るのがいかにもpascalっぽい
自作型のPropertyならばEditorも自作したほうが幸せなことが多い。
どんな素頓狂なプロバティが存在するか分かりませんからね。
なのでcomponent作者はそのcomponent用のEditorを一緒に配布することが多いです。
#なおEditorはあくまで編集用の道具ですので、componentとは違って、作るexecutableには
#リンクさせないのが普通です。実行時にも自らを編集させたい(!)ときは別ですが。
で、delphiならば、このPropertyEditorのメンバとして選択用ダイアログを持たせるでしょうね。
ふつーはPropertyWindowの中でちまちま活動するPropertyEditorですが、
いざ(?)となったらダイアログだろうがなんだろうが立ちあげて奮闘するようにすればいいんです。
#delphでの実例では、絵を表示するcomponentに最初から絵を埋めこんじゃいたいときに
#ファイル選択dialogを出してファイルを選ばせちゃうってのとか、
#色指定dialogを出してcomponent各部の色を好きに設定させたりとか。
こうすればcomponent instance(の雛型)の1つづつに自在に対応エディタを割りあてられる。
対応エディタ(たぶんプログラム名のstring)プロパティに、そういう仕掛をしたPropertyEditorを
わりあてればよい。
Re:gvimじゃないのかぁ。 (スコア:1)
1: 編集「する」Objectと「される」Objectとがはっきりわかれるべし。
2: 「される」ほうは生成されるアプリに、「する」ほうは開発環境に、リンクされるべし。
ってのを満たすと、いろいろ幸せになれるよね、ということです。
遠い昔の記憶 (スコア:0)
あのころはサクサクと軽かったよなぁ...
Re:遠い昔の記憶 (スコア:1)
参考までにお聞きしますが、その後どのような環境に移ったのでしょうか? > AC 氏
Re:遠い昔の記憶 (スコア:0)
今は、
自宅でmew+xemacsとぽすぺ+おやつとお部屋いっぱい。
会社でNotes。
どれも重すぎ。
Re:遠い昔の記憶 (スコア:0)
これこそGNOME (スコア:0)
いやはや… (viオタってすごいですね)、という話にとらえてるなら、いかに もUNIXユーザー的視野狭窄な見当違い。アプリケーションの連携となるとまっさきにパイ プのメリットを持ち出すわりに、コンポーネントにはいまいち理解を示さない のは、いったいどうしてか不思議。
Wordの文書にExcelの表を貼り付けられるのは知ってますよね。WindowsではIE コンポーネントでHTMLを表示するソフトとかがいっぱいあって、「ソフトウェ ア部品の共用」が身近だけど、UNIXではサッパリ。GNOMEは、その差を一気に 縮めようとしてるんです。
Re:これこそGNOME (スコア:1)
ミスマッチかなあ?
俺はマヂでviが使いやすいエディタだと思っているし
あの素朴な(笑)表示形態には何ら罪がないと思っているんで。
jvimはwindowsでも使っています。俺のメインエディタっす。
それにvi独特の操作体系だけじゃなくGUI的にも使えるわけっしょ?
ミスマッチとは思えないんだけど。
つまりさ、viとunixってのは実は、文化的慣習的な面をのぞけば、
全然関係ない、んだよね。単なるエディタの1流派。
#つまり、oopオタ(おれがか?)だってvi使うんすよ。ええ。
さて、採用したのがviかどうかという話はさておき、
>いかにもUNIXユーザー的視野狭窄な見当違い。アプリケーションの連携となるとまっさきにパイプのメリットを持ち出すわりに、コンポーネントにはいまいち理解を示さないのは、いったいどうしてか不思議。
こっちは、時折感じるんだよな。
前述の「もうちょっとましに」もそうだし、
あと(これも既に書いたが)http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=UNIX%A4%C8%A4%A4%A4%A6%B9%CD%A4%A8%CA%FD
に書いたけど、そもそも「部品化」にも色んな方向性があり、
unixのpipeはそれらのうちの1つでしかなく、
しかもoop的な部品化のパラダイムよりもやや低機能、なんだよねえ。
つまりそういうこと。
で、「普通のやつらの上を行け」でいう「hoge言語のパラドックス」ってやつのように、
自分が慣れた世界より高機能な世界を人間は「理解」しにくいようです。
「どうしてか?」と問われれば答えはそれですね。
#winユーザーだってつまりは「慣れて」いるだけなんだよね。
というわけで人は、特定のアーキテクチャに「(行動としてはともかく、思想までもが)慣れ」すぎてしまうと、
世の中のハッピーの数を増やす活動(^^;;には加わりにくくなるでしょうね。
>WindowsではIE コンポーネントでHTMLを表示するソフト
そういやdelphiにもhtmlコンポがありますね。
ところでコンポーネントのアーキテクチャにも色々ありますね。
delphiみたいに、instanceのプロセス間移動(?)をサポートしてない軽量コンポも有るし。
単にアプリを作るだけなら、あーいうのも便利です。
Re:これこそGNOME (スコア:1)
基本的に「ファイル/プロセス/コマンド」というレベルでの部品化を主眼としているのであって、
「オブジェクト/スレッド/関数」での部品化には興味がないんでしょ。
たとえば Apache には設定ファイル書き換え用のアプリなんてものは存在しない。
vi でも emacs でも cat でも、どれでも設定変更できる。
何の手間もかからずにユーザの好きなように組み合わせられる。
COM/CORBA での部品の組み合わせは、ある程度の開発者じゃないとできない。
というのは部品の関係が密すぎるから。
従って、組み合わせるのに手間がかかるし、誰でもできるわけじゃない
（もちろんその分、スムーズな組み合わせになるし、
同じ組み合わせを繰り返すのも楽だけど）。
結局、その方法では「開発者」と「エンドユーザ」を完全に切り離す方向だし、
それはあまりUNIX的ではないと思う（それなら Mac のようなものが既にある。
カーネルはUNIXだけど、文化としてはUNIX的ではない）。
コマンドライン程度の記述やシェルスクリプトで、
部品組み合わせの方法論が見つかればいいんだろうがね。
（あるいはそれは tcl のような道ではないかと思うけど）
> WindowsではIE コンポーネントでHTMLを表示するソフトとかがいっぱいあって、「ソフトウェア部品の共用」が身近だけど
Unix 的には「どうしてメーラの中でHTMLを表示するようなことが必要になるの？
HTMLをファイルで保存してブラウザで開くようにしておけばいいでしょ？」
ってことかと。
# mishimaは本田透先生を熱烈に応援しています
Re:これこそGNOME (スコア:1)
>というのは部品の関係が密すぎるから。
それはなんか違うなあ。
oopの中でもC++みたいながちがちのコンパイラの下僕な世界ならともかく、
COM/CORBAみたいに柔らかいほうになってくると、
実行時にそのへんはいじれるはずなんだよね。
逆にいえばunix世界だって、「そのまま」だったら
なにかするたびにC言語でがちゃがちゃ書かないとならなかったはず。
そうじゃない現実があるのは何故かってーと、「shell」が、あるからなんだよね。
部品たるコマンド間の結合を固定せず、動的に結合できるようにしてあって、
そこに人間さまが介入できるような仕掛としてshellがある、という構図。
ならば、oopにだって「shell」を作ればいいんです。
そして、なんかあんまり見かけませんが(笑)、できるはずなんです。
##あ。squeakなんかは全身がshellみたいなもんだな。
関係が密てのも、なんか違う。
unixのprocessだと、口は"stdin,stdou,stderr"という
機能も名称も個数もキメウチだというガチガチなんで、
対応する側にもバリエーションが求められないけど、
objectだと機能も名称も個数も色々な口があるんで、
バリエーションへの対応を考えないとならない。
で、C++ならともかく、上記のようなやつらだと、
Interfaceを動的に取得できるじゃん。
なんて名前/型のメソッドがあるか?とか検索できる。
それに基づいてshellも動けばいいわけです。
関係が密ってわけじゃない。単にバリエーションがあるだけで、その間柄は
いくらでも引き剥すことができます。もちろん繋ぎなおしも。それをやるのがshell。
少なくとも「誰でもできるわけじゃない」ってことは無いでしょう。
さもないとoopベースのGUI RADなんてものが成り立っている理由が説明できない。
そこそこ扱いやすいshellさえあれば、概念レベルでの困難なんて特に無いんです。
というか、 unixを楽々使えるような最低限きちんとした技術を持ってるような人々が
メソッド名がキメウチじゃなくなったという程度(^^;の複雑さの増加ごときで
音をあげる(EndUserとして「切り離される」)と思いますか?
なんか変じゃないですかそれ?
viやemacsを/usr/云々から自在に「さがす」ことができる人ならば、
あるobjectの「使いなれた」メソッドを「さがす」ことだって、容易なはずでは?
だから、そういう意味において
>それはあまりUNIX的ではないと思う
という指摘は、当ってないと思います。
macですか? 作って地獄とよばれた往年のあの頃と、今を一緒にしないでくれ、って感じです。
VB(悔しいが)以降、というかそれこそHypercard以降、世界はかわったんです(と聞いてます)。
なおOSXのことでしたら、なんかRuby/Cocoaとかいう単語がMLで聞こえてきていますが…
>（あるいはそれは tcl のような道ではないかと思うけど）
まぁそれでもいいです。rubyに色々bindしたりとかね。
で、そういうテキストベースでもいいし、そうでなくてもいい、と。
#というか、unixのshellに相当するものをGUIで作った人もいたよね。たしか投げるshell(正式名称失念)とか。
>Unix 的には「どうしてメーラの中でHTMLを表示するようなことが必要になるの？
>HTMLをファイルで保存してブラウザで開くようにしておけばいいでしょ？」
メーラーにHTMLを使うという腐った選択をしたかどうかは、ここでは問題ではないのでは?
ふつーのエディタについて考えても同じ議論ができるような、そういう問題でしょう。
いいかえるべきですね。任意の(htmlじゃなくplaintext用の)エディタを
自分のすきな任意のアプリの中で使えますか?という問いだと思えばいい。
あとついでに言えば、What you see is What you getは、
まやかしも含んでいますが、真実も含んでいます(^^;