アカウント名:
パスワード:
このコンポーネントがkeystrokeを、内部に起動しているvimに送って、出力をコンポーネントに表示する模様。
どっちかってーと俺も書いたように、「お好きなエディタを使えますぜ」的な ソリューション(死語?)に向いたやり方かなーと。
該当メーラーのエディタ部分「が」そのクラスだったんで、今回もそれに合わせた、 ってことだったりするでしょうか? なんせアウトルックとかいうアレのCloneなんですよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
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: 「される」ほうは生成されるアプリに、「する」ほうは開発環境に、リンクされるべし。
ってのを満たすと、いろいろ幸せになれるよね、ということです。