blogに引っ越しました。0.4.0のうち、使用しているファイルを添付その他不具合修正いやdisってないですって!!!すべてぼくのミスです!!!^p^1.8で使ってる人、多いんだなぁって驚きました。ubuntuと謳っているのでそりゃあそうか。1.8で使う日と1.9の日を交互とかでやるか。ユニットテストで追い切れない部分は使わないとどうしようもないしね。ここからは特に目立った機能追加はせずにバグを取って、0.0.4を目指そうと思います。UIをつかえることになりますね。release2011年5月27日金曜日mikutterコマンドプラグイン開発のおはなし。プラグインは、結構簡単に自分のタブをつくることができるようになってる。その方法は既存のcore/addon/friend_timeline.rbとかを見ればすべてわかるので省略するけれど、これだけじゃあプラグインには不十分なことがある。指定された特定のつぶやきに対して動作するものは、タイムライン上でつぶやきを右クリックしてメニューで選べると良い(コンテキストメニュー)。プロフィール表示はただのプラグインだけど、コンテキストメニューに「〇〇のプロフィール」という項目が出てくる。これは、今まで「コンテキストメニューフィルタ」というのを使ってて、イベントフィルタで右クリックメニューをガシガシ追加できるというものだった。0.0.3.5からはキーコンフィグで右クリックメニューで出てくるものにキーを割り当てることができるようになったので、ユーザは前より柔軟にカスタマイズができるようになった。そんなふうに、コンテキストメニューやショートカットキーにプラグインが追加できる機能、mikutterコマンドを新しく追加しました。}これは会話スレッドプラグインの、登録している箇所。(core/addon/smartthread.rb)。だいたいこれをテンプレに使って頂けたらとおもうんだけど、menuという連想配列に入れる内容がポイント。:slug一意なコマンド名。かぶっちゃいけないので、プラグイン開発者の独創性が試される。しておけってこった:name表示名。コンテキストメニューに表示される内容。String:descriptionこの機能の説明など。:iconアイコンがあれば。今のところ使われない。Gdk::PixbufとかString(ファイル名)を指定しましょう。:condition実行条件。これの値と===で引数(後述)が比較される。1.9では、Proc#===は、Proc#callのことなので、無名関数を渡すとなんでもできる。1.8でも、utils.rbで同じ機能が実装してあるので使ってください。:exec実行される本体。:conditionと同じ引数を受け取るが、:conditionがfalseになった場合はそもそもこれは呼ばれない。:visibleコンテキストメニューに表示するかどうかのフラグ。falseなら表示されない。これは例えば、「ひとつ上のつぶやきを選択」のように、コンテキストメニューに表示する意味がないもののためにある。:roleコマンドを実行できる環境。つぶやきを右クリックすると、ここに:messageが指定されたもののうち、:conditionがtrueなものだけが実行又はコンテキストメニューに表示される。指定できるもののバリエーションは後述。:conditionの「引数」というのは、:roleに何を設定したかによって変わる。:messageつぶやきにフォーカスがあるとき。以下のような構造体が引数になる。(Gdk::MiraclePainter)):message_select:messageの時で、なおかつテキストが選択されているとき。:timelineタイムラインで右クリックされたとき。基本的に:messageと同じタイミングだけど、引数はGtk::TimeLineしか受け取らないという点がちがう。:postboxつぶやき入力欄。今のところ、ショートカットキーにしか対応していない。引数としてGtk::PostBoxを受け取る。いうふうに、わりと簡単にmikutterコマンドを新しく追加できる。プラグインに依存しない機能(リプライとか)は、core/addon/contextmenu.rbに実装してあるので、例が見たければこれをどうぞ。これで随分プラグインの幅が広がるような気がします。新UIについてこんばんわ。先程新UIをリリースしました!何がどうなったのか簡単に説明するよ。mikutterの従来のレンダリング方法いままでのmikutter。動作は察してください。今までのmikutterは、ウィジェット※1を綺麗に並べてタイムラインを実現していました。この方法だと、あらゆるウィジェットを使用することができるので、タイムラインのレンダリングがとても自由にできます。※1...ウィンドウのパーツのことしたがって、mikutterのタイムラインは他のTwitterクライアントのそれに比べてかなりリッチな部類だと思います。なかでも、アイコンオーバーボタン(アイコンにマウスカーソルを重ねるとボタンが出てくる機能)、ふぁぼられ、リツイート累積表示、リプライ宛先表示などのmikutterの代表的な機能は、この方法でタイムラインをレンダリングしたからこそ容易に達成できた、という背景がありました。何が悪いのか本来、ウィジェットは頻繁に追加削除されるものではないので(大体は作ったらそれでおしまいですよね)、ある程度タイムラインの流れが速いと、異常な速度でウィジェットの作成/削除/パッキングが行われます。配置の自由度が高いぶん、こういった変化があったときの再描画のコストは馬鹿になりません。Ubuntuの最新版に入っているRubyGTKはとても古く(nattyには0.19.3が入っているが、最新は0.90.8)、大量のバグが含まれているのが現状です。Faultしてmikutterが巻き添えになることがしばしばありました。他のTwitterクライアントのレンダリング夜フクロウ。Linuxじゃない、Rubyじゃない、Gtkじゃない。リストビューっぽいですね。mikutterは他のTwitterクライアントと比較して、レンダリングが飛び抜けて遅いですね。説明は上記の通りだけど、ではどうしてそんなことをしたかというと、現在のmikutterは、とりあえず表示できるものを仮に作った段階だったのです。mikutterのUIは新たにつくり直す必要がありました。他のTwitterクライアントはどうしているかというと、リストビューを使用していると思われます。リストビューは、パーツが縦に並ぶことを前提にしているのでどうやら速いらしい。ソートオーダーなどの細かい話もGtkがやってくれるのでRubyでやるよりは早くなりそう。リストビューにすればいいじゃない、と簡単にはいかない。いうのも、この中に置けるのは、せいぜい画像と文字くらいだからで、新しいRendererを作成するにしても、今までのように好きなウィジェットを思いのままに設置するとはいきません。高速になったが見た目はそんなに変わらない。全部画像にしたらよくね!?という奇想天外なことを思いつきました。画像だったらすきにレンダリングできるけれど、キャッシュすれば速さもでるんじゃねーのと思ったわけです。リストビューは、任意のRendererを設定できるので、今回は実際にTLを描画するやつをMiraclePainterという名前にしました。TLの先まですべてミク色に染めていただきましょう!!!で、リッチな表示ができないとか言ってたけど蓋を開けたら右のようになってます。ついでだから微妙にマイナーチェンジしましたが。Faultの確率が減るかも!?と、圧倒的な進化を遂げました。CPU使用率も大幅に減ったので、いままで遅くて使えんと言っていた人もつかえるようになるんじゃないかな。そのためには、ショートカットキーなどの処理をもっときめ細かにやっていかないといけないと思っていて、例えば横のタブにフォーカスとか、リプライ後のフォーカス移動とか、そういうところに気を配らないとなぁ、と思ってます。ウィークリーリリース版に適応されています。右クリックメニューでできること全てにショートカットキーを割り当てられるようにしましたTLのレンダリング方法を革命的に変えました。設定と環境によっては過剰にAPIを消費することがある不具合とりいそぎでかいのだけ。有意なレポートがないのでこっちで再現したぶんだけ修正しています今回は静かですねーなんっでっかなー(新UIについてはまだです。それについては前回の記事を。ほとんどできているので、今週中にtrunkにマージして、1〜2回のウィークリーリリースを経て0.0.4にできたらなぁと考えています。なんか最近なんもしてないのに同じような不具合がたくさん報告されてくるのあれなんだろう。release2011年5月14日土曜日cairo版と言われてるものについてひっそりやってたんだけど思ったより拡散したので、解りづらい形式で説明します。説明に時間を食いたくないので簡単に。cairo版とは萌ゆいものとかわいいものが一緒になってやばいです具体的に何をしたの?タイムラインをリストビューにして、各セルをcairoでレンダリングしています。見た目はできるだけ今までと変わらないようにしています。別にcairoを使ったことだけが新しいわけじゃないんだけど、それに気づいたときにはみんな知ってたのでておくれました。何が良いのか高速になって、メモリ消費が少なくなって、ライブラリのバグを踏む確率が下がることを期待しています欠点はとくになし。リプライのUIが若干変わってしまうかも。これは最終的に従来の方法を実現できる可能性がある。それさえなければ欠点は特になさそうどうやって使うのかtrunkには入っていません。以下のリポジトリからチェックアウトしてください。svn://toshia.dip.jp/mikutter/branches/cairouiただし、未実装の部分が多く、クリックするとクラッシュするボタンがあったりします。なるまで待てないという早とちりな人用です。進捗を見たいここでやってます。http://dev.mikutter.hachune.net/issues/131バグ報告など上のチケットの中になければ報告欲しい...といいたいところですが、リソースをこちらに集中して開発しているので、おそらくバグ報告は行き違いになると思います。mikutter上で設定もできます。release2011年5月2日月曜日MUiなんとなくできてきた、ような...あれから紆余曲折あったけどMUiが構想からなんとなく動くものになってきた。Kitだったしねできるだけ、SXMLをそのままUIとしてレンダリングしたい!...と思っていたわけなんだけど、実際の動くコードは今こんなかんじ。world"))mui()というのは、jQueryで言うところの$()みたいなものと思っていただければ。$("<div>")とかやるじゃんこれが実際何をしているかというと、引数をMUiのGtkプラグインで定義されるオブジェクトでラップしたものを返してます。そのクラスはMUiBaseクラスのサブクラスで、MUiBaseはArrayのサブクラス。中身の値も渡された配列と全く同じになるようにコピーされます。渡された配列にいろいろextendしていく方法とこちらの方法で迷ったんだけど、extendする方法だと、freezeされた配列が渡されてきたときにエラーにせざるを得ないのと、この方法なら、同じ配列を雛形にして何度もMUiオブジェクトを作れるというメリットがある。DOMにはイベントのAPIで、AddEventListenerというのがあるので、ちょちょいと実装しました。これといって特筆することはないです、単に、第一引数にイベント名を取って、イベントが呼ばれたらブロックが実行されるだけなので。いうやつは、「windowウィジェットの子の中で要素名がbuttonのもの」という意味です。最終的にはCSSセレクタまがいなことが出来れば、と思ってる。少なくとも#.くらいは使えたほうがいいかとか。今は最初にマッチしたものを返してるだけなんだけど、jQueryって、複数返って来た時に、呼ばれたメソッドを各ウィジェット毎に繰り返し適用してるよね?あれ便利だけどどうなのかな。...というわけで実行したらこうなります\(^o^)/ポイントとしては配列でいいんだし、複雑なのは外部からYAMLで流しこめばいいでしょイベントのバインドはらくらく意外とメリットが少ない...もちろんMUiプラグインをgtk以外のものにすればいろいろ応用がきく、というのはちゃんと視野に入ってますよ。