mikutterの最新の情報は、mikutter blogに引っ越しました。

2011年5月28日土曜日

#mikutter 0.0.3.6

はいはーい

  • ruby1.8で、タイムラインの右クリックメニューが表示されない
  • ruby1.8で、ショートカットキーの新規割り当てで確実にクラッシュする
  • ruby1.8で、MiraclePainterが更新された時にSegmentation faultする
  • ruby1.8で、文字列選択でクラッシュする
  • ミュートしたユーザがTLに表示される不具合
  • リツイート、リツイート解除、のmikutterコマンドの修正
  • ふぁぼ解除のmikutterコマンドの追加
  • 選択範囲をgoogleで検索
  • ruby-hmac 0.4.0のうち、使用しているファイルを添付
  • その他不具合修正
いやdisってないですって!!!すべてぼくのミスです!!!^p^

1.8で使ってる人、多いんだなぁって驚きました。ubuntuと謳っているのでそりゃあそうか。これからは十分速くなったのでruby 1.8で使う日と1.9の日を交互とかでやるか。ユニットテストで追い切れない部分は使わないとどうしようもないしね。

ここからは特に目立った機能追加はせずにバグを取って、0.0.4を目指そうと思います。またruby1.8ではこのバージョンから実質new UIをつかえることになりますね。うへへヾ(@⌒ー⌒@)ノ


2011年5月27日金曜日

mikutterコマンド

プラグイン開発のおはなし。

プラグインは、結構簡単に自分のタブをつくることができるようになってる。その方法は既存のcore/addon/friend_timeline.rbとかを見ればすべてわかるので省略するけれど、これだけじゃあプラグインには不十分なことがある。

例えば、指定された特定のつぶやきに対して動作するものは、タイムライン上でつぶやきを右クリックしてメニューで選べると良い(コンテキストメニュー)。
例えば、プロフィール表示はただのプラグインだけど、コンテキストメニューに「〇〇のプロフィール」という項目が出てくる。これは、今まで「コンテキストメニューフィルタ」というのを使ってて、イベントフィルタで右クリックメニューをガシガシ追加できるというものだった。

0.0.3.5からはキーコンフィグで右クリックメニューで出てくるものにキーを割り当てることができるようになったので、ユーザは前より柔軟にカスタマイズができるようになった。
そんなふうに、コンテキストメニューやショートカットキーにプラグインが追加できる機能、mikutterコマンドを新しく追加しました。
今回はその話。

    plugin.add_event_filter(:command){ |menu|
      menu[:smartthread] = {
        :slug => :smartthread,
        :name => '会話スレッドを表示',
        :icon => MUI::Skin.get("list.png"),
        :condition => lambda{ |m| m.message.repliable? },
        :exec => lambda{ |m| tabclass.new("Thread #{counter.call}", service,
                                          :message => m.message,
                                          :icon => MUI::Skin.get("list.png")) },
        :visible => true,
        :role => :message }
      [menu]
    }

これは会話スレッドプラグインの、登録している箇所。(core/addon/smartthread.rb)。だいたいこれをテンプレに使って頂けたらとおもうんだけど、menuという連想配列に入れる内容がポイント。

:slug
一意なコマンド名。かぶっちゃいけないので、プラグイン開発者の独創性が試される。Symbolで何か。まあおまえら初心者は、:プラグイン名_機能名 にでもしておけってこった
: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
    つぶやきにフォーカスがあるとき。以下のような構造体が引数になる。
    Struct.new(:event (Gdk::Event or nil), :message (Message), :timeline (Gtk::TimeLine), :miraclepainter (Gdk::MiraclePainter))
  • :message_select
    :messageの時で、なおかつテキストが選択されているとき。引数も同じ。
  • :timeline
    タイムラインで右クリックされたとき。基本的に:messageと同じタイミングだけど、引数はGtk::TimeLineしか受け取らないという点がちがう。
  • :postbox
    つぶやき入力欄。今のところ、ショートカットキーにしか対応していない。引数としてGtk::PostBoxを受け取る。
こういうふうに、わりと簡単にmikutterコマンドを新しく追加できる。プラグインに依存しない機能(リプライとか)は、core/addon/contextmenu.rbに実装してあるので、例が見たければこれをどうぞ。

これで随分プラグインの幅が広がるような気がします。おもしろいものをつくってね!!!

2011年5月23日月曜日

新UIについて

こんばんわ。先程新UIをリリースしました!何がどうなったのか簡単に説明するよ。

mikutterの従来のレンダリング方法

いままでのmikutter。見た目はリッチ。
動作は察してください。
今までのmikutterは、ウィジェット※1を綺麗に並べてタイムラインを実現していました。この方法だと、あらゆるウィジェットを使用することができるので、タイムラインのレンダリングがとても自由にできます。

※1…ウィンドウのパーツのこと

したがって、mikutterのタイムラインは他のTwitterクライアントのそれに比べてかなりリッチな部類だと思います。なかでも、アイコンオーバーボタン(アイコンにマウスカーソルを重ねるとボタンが出てくる機能)、ふぁぼられ、リツイート累積表示、リプライ宛先表示などのmikutterの代表的な機能は、この方法でタイムラインをレンダリングしたからこそ容易に達成できた、という背景がありました。

何が悪いのか

本来、ウィジェットは頻繁に追加削除されるものではないので(大体は作ったらそれでおしまいですよね)、ある程度タイムラインの流れが速いと、異常な速度でウィジェットの作成/削除/パッキングが行われます。
配置の自由度が高いぶん、こういった変化があったときの再描画のコストは馬鹿になりません。また、Ubuntuの最新版に入っているRubyGTKはとても古く(nattyには0.19.3が入っているが、最新は0.90.8)、大量のバグが含まれているのが現状です。そのようなAPIに頻繁にアクセスするので、ライブラリがSegmentation Faultしてmikutterが巻き添えになることがしばしばありました。

他のTwitterクライアントのレンダリング

夜フクロウ。
Linuxじゃない、Rubyじゃない、Gtkじゃない。
けどリストビューっぽいですね。
mikutterは他のTwitterクライアントと比較して、レンダリングが飛び抜けて遅いですね。説明は上記の通りだけど、ではどうしてそんなことをしたかというと、現在のmikutterは、とりあえず表示できるものを仮に作った段階だったのです。つまり、mikutterのUIは新たにつくり直す必要がありました。

では、他のTwitterクライアントはどうしているかというと、リストビューを使用していると思われます。
リストビューは、パーツが縦に並ぶことを前提にしているのでどうやら速いらしい。ソートオーダーなどの細かい話もGtkがやってくれるのでRubyでやるよりは早くなりそう。

しかし、じゃあリストビューにすればいいじゃない、と簡単にはいかない。というのも、この中に置けるのは、せいぜい画像と文字くらいだからで、新しいRendererを作成するにしても、今までのように好きなウィジェットを思いのままに設置するとはいきません。

Cairo+リストビュー

新UI。かなり高速になったが見た目はそんなに変わらない。
じゃあ、全部画像にしたらよくね!?という奇想天外なことを思いつきました。画像だったらすきにレンダリングできるけれど、キャッシュすれば速さもでるんじゃねーのと思ったわけです。

リストビューは、任意のRendererを設定できるので、今回は実際にTLを描画するやつをMiraclePainterという名前にしました。TLの先まですべてミク色に染めていただきましょう!!!

で、リッチな表示ができないとか言ってたけど蓋を開けたら右のようになってます。ついでだから微妙にマイナーチェンジしましたが。これがどの程度速くなったかは、実際に起動してもらったほうがよさそうなのでここでは書かないけれど、

  • ボトルネックになってた部分は100倍くらいの効率のアップ
  • 起動時間は2秒
  • 新しいタブを作ったりした時にブラックアウトすることもなくなった
  • 入力中に固まってイライラすることもなくなった
  • RubyGtkのAPIを叩く回数が減ったので、Segmentation Faultの確率が減るかも!?

と、圧倒的な進化を遂げました。CPU使用率も大幅に減ったので、いままで遅くて使えんと言っていた人もつかえるようになるんじゃないかな。

ただそのためには、ショートカットキーなどの処理をもっときめ細かにやっていかないといけないと思っていて、例えば横のタブにフォーカスとか、リプライ後のフォーカス移動とか、そういうところに気を配らないとなぁ、と思ってます。

現在この最適化は、0.0.3.5 ウィークリーリリース版に適応されています。これからバグを取ったり最適化をする段階だけど、興味がある人は是非!!!

#mikutter 0.0.3.5

さあドッグフードを食え!!!

  • TLのレンダリング方法の変更
    • 高速化しました
      • 一部機能はまだ実装中です
  • ショートカットキーの設定の大幅刷新
    • 右クリックメニューでできること全てにショートカットキーを割り当てられるようにしました
TLのレンダリング方法を革命的に変えました。そんで今回は、久しぶりにバグてんこ盛りのウィークリーリリースになってます!!これからなおしていこう!!!

2011年5月16日月曜日

#mikutter 0.0.3.4

みんな元気ー(^p^)つ!?またゴールデンウィーク来ないかなーーーー!!!ヾ(@⌒ー⌒@)ノ



はぁ

  • PIAPRO画像プレビュープラグインの修正
    • PIAPROの仕様変更に対応
  • 設定と環境によっては過剰にAPIを消費することがある不具合
    • とりいそぎでかいのだけ。有意なレポートがないのでこっちで再現したぶんだけ修正しています
今回は静かですねーなんっでっかなー(

新UIについてはまだです。それについては前回の記事を。ほとんどできているので、今週中にtrunkにマージして、1〜2回のウィークリーリリースを経て0.0.4にできたらなぁと考えています。

なんか最近なんもしてないのに同じような不具合がたくさん報告されてくるのあれなんだろう。mikutterも五月病なのかなだらしねぇな ←

新UIが安定したら0.1あるでと思ってます、応援してね!!!

2011年5月14日土曜日

cairo版と言われてるものについて

ひっそりやってたんだけど思ったより拡散したので、解りづらい形式で説明します。
あまり説明に時間を食いたくないので簡単に。

cairoとは

すごくかわいくなります

mikutter cairo版とは

萌ゆいものとかわいいものが一緒になってやばいです

具体的に何をしたの?

タイムラインをリストビューにして、各セルをcairoでレンダリングしています。見た目はできるだけ今までと変わらないようにしています。
だから別にcairoを使ったことだけが新しいわけじゃないんだけど、それに気づいたときにはみんな知ってたのでておくれました。

何が良いのか

高速になって、メモリ消費が少なくなって、ライブラリのバグを踏む確率が下がることを期待しています

欠点は

とくになし。ただし、リプライのUIが若干変わってしまうかも。これは最終的に従来の方法を実現できる可能性がある。
それさえなければ欠点は特になさそう

どうやって使うのか

trunkには入っていません。以下のリポジトリからチェックアウトしてください。
svn://toshia.dip.jp/mikutter/branches/cairoui
ただし、未実装の部分が多く、クリックするとクラッシュするボタンがあったりします。あくまで、ちゃんとなるまで待てないという早とちりな人用です。

進捗を見たい

ここでやってます。 http://dev.mikutter.hachune.net/issues/131

バグ報告など

上のチケットの中になければ報告欲しい…といいたいところですが、リソースをこちらに集中して開発しているので、おそらくバグ報告は行き違いになると思います。

2011年5月7日土曜日

#mikutter 0.0.3.3

みんなみてるぅー?いえーいヾ(@⌒ー⌒@)ノ

  • プロキシサーバを利用してアクセスする機能
    • デフォルトでは、環境変数 HTTP_PROXY の内容を利用します。mikutter上で設定もできます。
    • @osa_kさんにプラグインをいただきました!
  • Growlを利用した通知に対応
    • @katsyoshiさんにパッチをいただきました!
  • SDLを用いたサウンドの再生
    • 同上
  • debian系OSで、mikutterを動作させるために必要なアプリケーションをビルドするスクリプトを同梱
  • 鍵付きアカウントのつぶやき取得に関する不具合
  • いくつかのクラッシュする可能性のあるバグ、最適化

遂にプロキシ機能付いたよ!これで一部大学・会社なんかのtwitterをブロックしているFW内からmikutterがつかえるね!やったねたえちゃん!







フフフヾ(@⌒ー⌒@)ノ

2011年5月2日月曜日

MUiなんとなくできてきた、ような…

あれから紆余曲折あったけどMUiが構想からなんとなく動くものになってきた。
MUiの略称は Mikutter UI くらいにしておこうとおもう。GTKだってGimp Tool Kitだったしね

できるだけ、SXMLをそのままUIとしてレンダリングしたい!…と思っていたわけなんだけど、実際の動くコードは今こんなかんじ。

require File.join(File.dirname(__FILE__), '..', 'mui')

MUi.toolkit = 'gtk'
window = mui([:window, [:button, 'hello, world']])
window.add_event_listener(:close){
  mui.mainloop_quit
}
(window / 'button').add_event_listener(:click){
  p 'clicked!!'
}
mui.mainloop

ドヤァ
まあ最初の方は授業とかでおまじないと言われるアレですね

window = mui([:window, [:button, 'hello, world']])

これは、以下のようなSXMLをRubyの配列で表現したもの

(window
  (button "hello, world"))

mui()というのは、jQueryで言うところの$()みたいなものと思っていただければ。$("<div>")とかやるじゃん
これが実際何をしているかというと、引数をMUiのGtkプラグインで定義されるオブジェクトでラップしたものを返してます。そのクラスはMUiBaseクラスのサブクラスで、MUiBaseはArrayのサブクラス。そして中身の値も渡された配列と全く同じになるようにコピーされます。

渡された配列にいろいろextendしていく方法とこちらの方法で迷ったんだけど、extendする方法だと、freezeされた配列が渡されてきたときにエラーにせざるを得ないのと、この方法なら、同じ配列を雛形にして何度もMUiオブジェクトを作れるというメリットがある。

そしてDOMにはイベントのAPIで、AddEventListenerというのがあるので、ちょちょいと実装しました。これといって特筆することはないです、単に、第一引数にイベント名を取って、イベントが呼ばれたらブロックが実行されるだけなので。

二つ目のイベントの

(window / 'button').add_event_listener(:click){
  p 'clicked!!'
}

window / 'button' というやつは、「windowウィジェットの子の中で要素名がbuttonのもの」という意味です。最終的にはCSSセレクタまがいなことが出来れば、と思ってる。少なくとも#.くらいは使えたほうがいいかとか。今は最初にマッチしたものを返してるだけなんだけど、jQueryって、複数返って来た時に、呼ばれたメソッドを各ウィジェット毎に繰り返し適用してるよね?あれ便利だけどどうなのかな。

…というわけで


実行したらこうなります\(^o^)/ポイントとしては

  • 配列でいいんだし、複雑なのは外部からYAMLで流しこめばいいでしょ
  • イベントのバインドはらくらく

意外とメリットが少ない…
もちろんMUiプラグインをgtk以外のものにすればいろいろ応用がきく、というのはちゃんと視野に入ってますよ。例えばまだ全然できてないけどマルチプロセス用のプラグインを指定すれば、gtkの時と全く同じようにマルチプロセスになるとか、ね。




・・・




・・・




・・・




やばいなんか微妙な気がしてきた大丈夫かこれうあああああ^p^