多言語対応
日本語以外を母語とするユーザが出てきはじめました。これを受けて、mikutter 3からはUIに表示する言語を、ロケールによって切り替えるようにしました。
マルチアカウント
単一のmikutterで、同時に複数のTwitterアカウントを扱えるようになりました。
現在選択されているアカウントは、プライマリアカウントと呼びます。
プライマリアカウントの切り替えボタンは、他の多くのTwitterクライアントに倣ってpostboxの左隣に置きました。クリックしたら表示されるドロップダウンメニューからアカウントを切り替えることができます。
また、mikutterコマンドでもアカウントを切り替えることができます。
二つ目以降のアカウントは、設定画面で追加します。
マルチアカウントについては、mikutterの薄い本vol.5のtoshi_aの記事でも触れているのですが、現在主流となっているそれとはちょっと違う仕様です。これについてはまたどこかで説明をするかも。
抽出タブの機能追加
抽出タブがアップグレードされました。
編集画面の刷新
抽出タブの編集画面が刷新されました。今まではタブには名前が表示されていましたが、他のタブのようにアイコンを設定できるようになりました。また、タブに新着通知機能がつき、任意の条件にマッチしたツイートがあるたび、効果音を鳴らしたりlibnotifyで通知を表示したりできます。
データソースの追加
今までデータソースは限られていましたが、マルチアカウント機能で追加された特定のアカウントのホームタイムライン・メンションをデータソースとして設定できます。
また、データソースをサードパーティプラグインから追加できます。これはすごいことですが、何に使えるでしょうか。
バージョン
今回から、独自のバージョニングをやめ、セマンティックバージョニングを採用します。この影響で、当初0.3と言っていた次のリリースは、3.0.0となります。
これは、mikutterのバージョン間の互換性をわかりやすくするためです。
新しいバージョニング
おおまかに言って、 「Major . Minor . TEENY」 という形式になります。
古いバージョニング
mikutterは、「0 . Major . Minor . BUILD」 という形式でした。BUILDというのはmikutterの開発が始まった日を0としての起算日です。また、先頭には意味のない0をつけていました。これは、何かミスった時に開発版ですしおすしと言い訳するための免罪符で、それ以上の意味を持ちませんでした。しかし昨今の拡がりを鑑みるに、これが免罪符として機能しない気がしてきたので、酔った勢いでこれを取り去り、ついでにセマンティックバージョニングを採用することにしました。
なぜ0.2から3.0は大幅に飛んでないのか
飛びすぎやろと言われることがしばしばありまくりますが、誤解です。まず、当初次回のバージョンは0.3を予定していました。これは古いバージョニングに当てはめると、以下のようになります。
0 . Major . Minor . BUILD
Major : 3
Minor : 0
0.3.0
これを、新しいバージョニングにそのまま当てはめます。
Major . Minor . TEENY
Major : 3
Minor : 0
3.0.0
0.2の次は3.0です。というより、0.2は新しいバージョニングに当てはめると2.0となります。何もおかしくない、順当な変化だということがわかりますね。
これからのリリース
今まではバグフィックスだと4桁目のビルド番号が増えていってましたが、これからはTEENYが増加します(3.0.0 → 3.0.1 → 3.0.2...)。ビルド番号は、これを書いている時点では互換性とかだるいとか忘れてたなどの理由まだついてますが、いずれ消えるでしょう。前よりガンガンバージョン上がっていく感じに思えますが、桁の問題ですね。飾りなのでこれくらい華やかな方がいいのかもしれません。
見えない変更
ライセンス
ソースコードのライセンスは mikutter 0.2.2 までは GPL3 でしたが、3.0 からは MIT ライセンスを採用します。この決定の経緯については、0.3の予定 とかを参照してください。
今までの設定ファイルには幾つか要望がありました。
- テキストエディタで読むことができない
- 極稀に壊れる
- プラグインが扱うデータベースがどこにあるか分からず、データの引き継ぎが困難
1.はそういう需要がいくらかあるということ。2.については、1.の問題のせいでどういう理由でエラーが発生しているのかわからないということ。3.については、データベース等大きなデータは設定ファイルに置くべきでないと言いながら、ではどこに置けばいいのかを明言していなかったため、プラグイン開発者が思い思いの場所に置いていたため、ユーザは設定を別の場所に引き継ぐ時に、どれが引き継ぐべきデータか分からないという問題がありました。
mikutter 3からは、設定をYAMLで保持します。場所も、 ~/.mikutter/p_class_value.db から ~/.mikutter/settings/setting.yml へ変更しました。前のデータからの引き継ぎは、アップデート後の初回起動時に自動的に行われます。
また、3.の問題に関して、各プラグインは ~/.mikutter/settings/[プラグインスラッグ]/ というディレクトリを持つことができ、この中に恒久的なファイルを置くことができます。ユーザはデータを移行する時、 ~/.mikutter/settings/ だけを移動してください。
また、プラグインから、この設定ディレクトリのパスを取得するときは定数 Environment::SETTINGDIR を使います。このあたりの話はWriting mikutter pluginにまとめておこうかと思います。
specファイルの名称変更
今まで、プラグインの依存関係等のメタデータは、各プラグインディレクトリに「spec」というファイルを設置して、その中に書くことになっていて、このファイルを設置することが推奨されていました。
しかし、このファイル名はRSpecのテストを設置するディレクトリ名と衝突しており、RSpecでテストを書くことができませんでした。そのため、他のツールと被ることがない名前にということで、「.mikutter.yml」を採用しました。もちろん3.0でもspecがあれば一応読みますが、これからリリース／アップデートするさいは .mikutter.yml も作成してください。尚、specと.mikutter.ymlを両方入れておくことで、0.2と3.0どちらにも対応できます。
書き忘れたこと
書き忘れたことはこの記事には書いてません。書き忘れたからです。
リリーススケジュール
連休後[要出典]くらいに最初のプレビュー版を公開する予定です。その後、１週間程度の頻度で何度かプレビュー版を公開し、5/31終了時点の状態を、mikutter 3.0.0として確定します。仮にここで不具合が取りきれなくても、その時点の状態がリリースされるということです。追々直していけばいいんですよ。1年ぶりにドッグフードを食べる時が来ましたよ！
