2012年9月18日火曜日
mikutter 0.2 開発版のテスト開始
若干日数がたってしまいましたが()、mikutter 0.2をtrunkにマージしたので、trunkを使っている人たちは、updateするともうmikutter 0.2がつかえるようになると思います。
で、これを以てバグ報告の受付を開始します。まだできてないこともあるけれど、数が減ってきたのである程度つかえるレベルになってきたと思います。さあ今こそかつての人柱魂を呼び起こす時だ!
A____A
|・ㅅ・|
|っ c|
| か |
| た |
| じ |
| け |
| な |
| い |
| ! |
| |
U ̄ ̄U
リリーススケジュール
Redmineのトラッカーが「機能」か「致命的」になっているものが全て完了した時点でRC1を公開(tarball)、致命的な不具合があれば修正して、数日サイクルでRCをリリースしていき、一週間大きな問題が見つからなければ0.2をリリースです。9/30あたりになればいいんだけどな。
新機能
ちょいちょい言ってますがざっとおさらい。
UI関連の内部APIの大幅変更
前回のエントリで説明したとおりです。人によっては、拾ってきて入れてるプラグインが対応して無くて起動できなくなると言ったこともあるでしょう。
マルチペイン
マルチペインに正式対応しました。二つ以上タブがあるペインのタブを右クリックすると、「新規ペインを作成」というコマンドが出てきます。これで新しいペインが一番左にできて、そのタブがそこに移動します。
今までの怪しい隙間にD&Dで増えるというのはないです。
ペインの構造が大幅に変わったので、0.1系のペイン情報は失われています。
設定
設定タブを廃止しました。ステータスバーの右にあるネギレンチアイコンをクリックすると、設定ウィンドウがポップアップします。設定はいままでどおり、触ったら即反映されます。決定ボタンなどはないので、設定が終わったらWMの機能を使って設定ウィンドウを閉じてください。
プロフィールプラグイン
プロフィールプラグインを書き直しています。レイアウトが大幅に変わったことと、ふぁぼ・ふぁぼられ数が見れるようになったことが変更点です。
フォーカス操作系のコマンド
左右のタブに移動する等、キーボード操作をしやすくするmikutterコマンドを大量に追加しました。ちょっとショートカットキーの割り当て画面考えないとそろそろきつくなってきましたね。
この世の全てをそこに置いてきた
いろんなプラグインにどさくさに紛れて隠し機能を追加しました。あと、いい忘れてる機能もありそうです。
バグ報告
クラッシュしたらレポートを送ってやってください。だけどバックトレースをコピペしてRedmineで適切に報告してくれたら、より早く対応できます。
バグ報告はRedmineでお願いします。Twitter上で報告されてもチケット化が追いつかないし、そもそもバグの報告から修正完了までの流れを扱うのに不向きです。また、流れが早いため他の人との情報の共有がうまく行きません。一応リプライで言われても聞きますが、基本的にTL上にいる時は休憩中なので、その場で聞いてるだけですぐに忘れる、ということがしばしばあります。人間だもの。
もちろん、質問はTwitterで結構です。でもアカウントを持ってる人には最終的なチケットの作成はお願いすると思います。
mikutterのRedmineアカウントを持っていない人で、報告するのに登録してやってもいいという方は、登録フォームから登録してください。ただしアクティベートは手動で行うので、登録したらリプとかで知らせてください。
チケット作成の流れはこちらの文書を参照してください。Redmineで残作業を確認するにはこちらから。コンソールのように、実装してあるのにまだチケットが残っているものは、現在作業中ということです。
今週は結構できるとおもうんだけどなーほんとに今月中にリリースとかできるんかな
2012年9月16日日曜日
mikutter 0.2 プラグイン移行ガイド
1 はじめに
まだバグは致命的なもの含めていくつか残ってますが、テストしてもらえる品質になったと判断したので、mikutter 0.2 を mikutter の trunk にマージしました。
今回のアップデートで、0.1 系と互換性が失われた部分がいくつかあり、プラグインを開発している人にはお手数ですが自分のプラグインに手を入れてもらわなけばいけなくなりました。
それもこれもクーラーが壊れたのが悪いんです。で、みなさんのプラグインをどうやって移行していけばいいかを簡単に説明します。 今回は、あくまで0.1用のプラグインが「動く」ようになることを主眼に説明します。 つまり、すべてをモダンな形式に書きなおす訳ではなく、互換性のあるところはできるだけ触らないようにして、 最小ステップで動くようにする方法を紹介します。 したがって、0.2対応のプラグインを書くためのドキュメントとしてはあまり使えません。
それもこれもクーラーが壊れたのが悪いんです。で、みなさんのプラグインをどうやって移行していけばいいかを簡単に説明します。 今回は、あくまで0.1用のプラグインが「動く」ようになることを主眼に説明します。 つまり、すべてをモダンな形式に書きなおす訳ではなく、互換性のあるところはできるだけ触らないようにして、 最小ステップで動くようにする方法を紹介します。 したがって、0.2対応のプラグインを書くためのドキュメントとしてはあまり使えません。
2 ざっくり
0.2 の目玉の変更はGUI関連に大幅に手が入ったことです。
これにより、複雑なGUIをもったプラグインが動作しない場合があります。
また、mikutterコマンドも変わったので、
もしあなたの作成したプラグインにmikutterコマンドを提供しているものがあるなら、
基本的には必ず書き替えなければならないと考えてください。
3 タブ
今までは、Gtkオブジェクトを作成して、 mui_tab_regist イベントでそれをGUIに渡して、適切な場所に配置されていました。
これからはGtkは基本的には使いません。全てはUI DSLを介して操作し、それをツールキットプラグインが表示する
というスタイルをとっています。こうすることで、mikutterをGtk以外で操作する方法を提供する余地を持たせたい、
という目論見があります。
とはいうものの、UI DSLはmikutterプラグインのほとんどのニーズを満たすために最適化されているため、複雑な
インターフェイスを定義することには向いていません。望むなら nativewidget メソッドを使ってタブの中に
Gtkオブジェクトを直接埋め込めますし、 mui_tab_regist も非推奨ですが残されています
(そして、いくつかのmikutterプラグインは未だにこの古い方法でタブを構築しています)。
ぶっちゃけて言えば mui_tab_regist はそのまま使える。Gtk::TimeLineもそのままでいい。
(Gtk::TimeLineは昨日あたりまでバグで動作してませんでしたが、今はもう大丈夫です)
あとどうでもいいんですけど、registっていう英単語はないんですってね。なんであると思い込んでたんだろう。 多分みんな使ってるから、調べもせずに日常的に使うようになってしまったんでしょうけど、 イベント名なので単純に変えられないし。早くこんな黒歴史イベント消し去りたいです。 このイベントを使わずにもっとクールに書く方法はあるんですが、今回の範囲外なのでカット。
あとどうでもいいんですけど、registっていう英単語はないんですってね。なんであると思い込んでたんだろう。 多分みんな使ってるから、調べもせずに日常的に使うようになってしまったんでしょうけど、 イベント名なので単純に変えられないし。早くこんな黒歴史イベント消し去りたいです。 このイベントを使わずにもっとクールに書く方法はあるんですが、今回の範囲外なのでカット。
4 設定
設定はポップアップウィンドウになりましたが、プラグインからsettings DSLを
使って設定を挿入することに変わりはありません。
これについても、内部のAPIは完全に互換性があります。
5 廃止されたイベント
内部でしかほとんど使っていなかったような、Gtk関係のフィルタを削除しました。残念ながら、見た目はほとんど
変わっていませんが、mikutterのUIの構造は大幅に変わっているので、安直に代替できるものはほとんどの場合ありません。
Gtkウィジェットのツリー構造を直接操作するようなプラグインも(多分見たことないけど)動かなくなります。
6 mikutter コマンド
おそらく一番多くの人にとって問題になるのはmikutterコマンドです。これは今回どうしても変更せざるを得ませんでした。
6.1 command メソッド
従来はmikutterコマンドを追加するためにはフィルタを用いていましたが、これからは command メソッドを使用します。
まずは従来の書き方をおさらいしてみましょう。
# in 0.1.x on_command do |menu| menu[:reply] = { :slug = :reply, :name => '返信', :condition => lambda{ |ms| ms.map(&:message).all? &:repliable? }, :exec => lambda{ |ms| ms.first.timeline.reply(ms.first.message, :subreplies => ms.map(&:message)) }, :visible => true, :role => :message } [menu] endこのモデルにはさまざまな問題があって、まずフィルタで受け取ったHashに、スラッグをキーにしてHashを入れる必要がありますが、 中に入れるハッシュの中にもスラッグを書いておかなければいけません。2つが違うと不具合が起こるので、 あまり好ましいAPIではありませんでした。 更に、フィルタなので、最後に引数を配列で返す必要があります。だいたいはスニペットで書いてしまうのでこれが問題になることは少ないですが、 ミスをする原因にしかなりません。 0.2では以上の点を改善しています。
# in 0.2 command(:reply, name: '返信', condition: Plugin::Command[:CanReplyAll], visible: true, role: :timeline) do |opt| opt.widget.create_reply_postbox(opt.messages.first.message, subreplies: opt.messages.map(&:message)) endcommandメソッドが追加されました。
command(slug, options, &proc)slug にスラッグを設定して、 options は従来渡していたHashと同じ物を渡します。ポイントは、slugを指定する必要が なくなったことです。 slug に設定されている値が流用されます。 更に、 :exec キー(コマンドの実行内容)も不要になり、 &proc を使うようになりました。これも slug のように中で Hashが加工されているとお考えください。というかそうなってます。
6.2 condition
condition キーに、従来は無名関数を渡していましたが、例では Plugin::Command[:CanReplyAll] という値が
設定されています。
これは単純に、よくある条件を定数にまとめたもので、あえて使う必要はありません。
すべての定数は mikutterの「core/plugin/command/conditions.rb」にまとめられています。
実は引数に渡される構造体にも若干の変化があるのですが、それは次の実行部分の話にまとめます。
6.3 ロール
どのウィジェット上でコマンドを実行するかを指定する部分で、条件や実行時に渡ってくる引数が変わります。
ただ、今まであった :message や :message_select のような、
直接存在しないウィジェットに紐づいていないロールは 廃止されています 。
0.2でも使用できるロールは、実際のウィジェットとして存在するもの、すなわち :timeline, :postbox です。
また、ウィジェット全てにロールが割り当てられたので、今までにはなかった :tab, :pane, :window,
:profiletab, :profile が新たに使えるようになりました。移植するのに新しいロールを使うことはない
と思うのでここでは割愛します。
6.4 条件及び実行時の引数
いままでは、ロールによって渡される引数が違いましたが、
これからはどのロールでも同じ構造体が渡されるようになりました。
Plugin::GUI::Event = Struct.new(:event, :widget, :messages)event には、mikutterコマンドがどのような入力によって実行されたかがシンボルで入っています。 基本的には :contextmenu (右クリックメニューから選択された)か :keypress (ショートカットキー)です (mikutter 0.2 からはmikutterコマンドを呼ぶデバイス等も拡張できます。だから :gamepad とか :kinect とかが入ってくる可能性があります)。 widget は、イベントが発生したウィジェットです。ロールが :timeline なら、必ずPlugin::GUI::Timeline のインスタンスが入ります。 最後の :messages は widget のアクティブな子ウィジェットを再帰的に探索し、タイムラインがあれば、 そのタイムラインでイベント発生時にアクティブだった Message の配列が渡されます。 これは Plugin::GUI::Timeline#selected_messages の戻り値ですが、 選択されているツイートに対して実行されるコマンドには必ずこの配列の内容を使ってください。 イベント発生時と実行時には微妙なタイムラグがある可能性があり、コマンドを実行した時に選択していたツイートと、 実際に実行された時に選択しているツイートが違う可能性があるからです。
6.5 具体例等
mikutterの core/plugin/command/command.rb に、たいがいのコマンドが定義されているので参考になると思います。
フィーリングでコピったらいけるでしょう。
7 定義ファイル
プラグインによっては、正しく書いているのにNoMethodErrorなどでクラッシュすることがあります。
理由はたいがい、guiプラグイン等がプラグインDSLにあとからメソッドを足しているケースがあり、これらの
プラグインよりそのプラグインが先にロードされていることが原因なんじゃないでしょうか。
0.2からはどのプラグインに依存しているかといった情報を書く定義ファイルが追加されたので、
依存するプラグインがあればそれを書いておくべきです。そうすれば、依存しているプラグインを先にロードしますし、
依存するプラグインが一つでも存在しなければ、ロードされません。
7.1 定義ファイルの書式
spec という名前のファイルを作成して、中にYAMLで記述します。
例えばダイレクトメッセージプラグインはこんなかんじです。
name: Direct Message slug: directmessage description: mikutterにリア充御用達機能ダイレクトメッセージを追加します。 送受信したすべてのDMを見るタブと、各ユーザのプロフィールにそのユーザと自分がやり取りしたDMを表示するタブを追加します。 depends: mikutter: "0.2" plugin: - gui - gtk version: "1.1" author: toshi_a
- name プラグインの通称です。日本語でもいいです。現在は使われませんが、インストールしてるプラグイン一覧みたいなのをそのうち作ってみたいですね。
- slug プラグインのスラッグ。依存関係の解決に使われます。
- description プラグインの簡単な説明。
- depends/mikutter 想定するmikutterのバージョン。ここに書いてあるバージョンと現在のmikutterのバージョンに 互換性がなければプラグインがロードされません。
- depends/plugin 依存するプラグインのスラッグ。今のところ、GUIがないと意味がないようなプラグインは gui を、 Gtkクラスを少しでも使っている場合は gtk を指定してください。DirectMessage は両方指定しています。 一つしかない場合も配列で指定してください。
- version プラグイン自体のバージョン。今のところ特に用途はありません。
- author プラグインの開発者のTwitterアカウントのscreen_name。これも今のところ特に用途はない。
8 まとめ
今回は当初の設計では想定していなかったことをいくつか実現するために、内部を大幅に書き換えたので、いくつか
プラグインの互換性がなくなってしまいました。mikutterは今まで、必ず過去のプラグインも動くようにしていたので、
今回手を入れたGUIまわりは、最初の設計が誤っていたと言わざるを得ないでしょう。
難しく言えば、クライアントに新たなユーザエクスペリエンスを提供するためにはアーキテクチャにイノベーションを起こすことが必要でした。 その代償としてコンパチビリティを失うソリューションしかトゥギャザーできなかったのは残念ですが、逆に言えば、 長いスパンで見ればプラグインデベロッパの開発コストを大幅に減らすオポチュニティと捉え、 プラグインDSLを拡張することによって新たなmikutterのコアコンピタンスを創出することができたので、 私とみなさんにとってWin-Winの変更になったと思う次第です。
mikutterのプラグインは本当にいろんなことができます。だから場合によってはここにある内容だけでは 移植することができないかもしれません。あと、なんか書き忘れてる気もします。 だから何かあれば適当に聞いてくれたらいいと思います。適当に答えますんで。
難しく言えば、クライアントに新たなユーザエクスペリエンスを提供するためにはアーキテクチャにイノベーションを起こすことが必要でした。 その代償としてコンパチビリティを失うソリューションしかトゥギャザーできなかったのは残念ですが、逆に言えば、 長いスパンで見ればプラグインデベロッパの開発コストを大幅に減らすオポチュニティと捉え、 プラグインDSLを拡張することによって新たなmikutterのコアコンピタンスを創出することができたので、 私とみなさんにとってWin-Winの変更になったと思う次第です。
mikutterのプラグインは本当にいろんなことができます。だから場合によってはここにある内容だけでは 移植することができないかもしれません。あと、なんか書き忘れてる気もします。 だから何かあれば適当に聞いてくれたらいいと思います。適当に答えますんで。
2012年9月4日火曜日
#mikutter 0.1.1.863
- Twitpicとinstagramの画像が表示できなくなった。仕様変更に対応
- mikutter.rbにシンボリックリンクを貼ってそれを起動すると起動できない問題
お久しぶりです。いかがお過ごしですか。自分の部屋にクーラー無くても、2回くらい頭痛と吐き気で動けなくなる程度で、基本的に生きていけることが分かりました。
ただし流石に40度を超えると怖いので、クーラーが生きてる部屋に逃げてしまいます。そうするとmikutterの開発が止まるので、mikutterのバージョンアップが一ヶ月以上空いた原因は、間違いなく夏にあります。
今回のアップデートについてはあまり話すことはありません。現在、0.2を開発中です。ですが、あまりにも抜本的な変更だったため、trunkに入れると一部trunkを常用している人の環境が破壊されるので、ブランチを一時的に切り替えていて、ある程度のところでtrunkにマージする、という手順で開発を進めていくことにしました。
0.2の現状
0.2はまだ不安定なので、うかつに起動すると、プロファイル等を壊し、mikutterを起動不能にし、あなたを一生童貞のままにしてしまう可能性があります。彼女はできたとしても財布しか見てません。
そのため、現在0.2は「開発者用プレビュー」です。αかな。プラグイン開発者とかは先に見ておきたいですからね。それから、バグ報告は受け付けていません。あまりにもバグが多すぎて、いちいちバグ報告を聞いている感じじゃないからです。
trunkに取り込んだ時(βくらい?)、RC(tarボールを公開した時)にここでもう一度記事にするので、テストしてみたい方はもうしばらく待っていてください。パッチはくれたら気温が低い日に取り込みます。
Twitterの規約の変更等を受けてのこれからのmikutterについて
最近話題になっています。これについて私から説明することはありません。Twitterの発表が全てです。ただ、mikutterがこれに対してどういう対応をするかはお伝えしておこうと思います。一言で言えば、まだ様子を見ているところで、今のところなにも行動していません。
今のところ問題視しているのは、Twitterの定める Display Requirements に従わなければならないようになったことです。mikutterでこれに従うことは、技術的にはそれほど難しいことではありませんが、これに従えば、mikutterの使い勝手を損なうことになるだろうと考えています。ではどうするのか…というのも実はまだ考え中なのですが、おそらくみんな似たようなことを考えているんじゃないでしょうか。どうしようもないことばかり考えてないで、週末のOSCに向けて日程を調整したほうが良いと思います。俺はいけないけどね。(mikutterマグカップが手に入るチャンスもあるとかないとか)
登録:
投稿 (Atom)