やること: チケット
https://dev.mikutter.hachune.net/
https://dev.mikutter.hachune.net/favicon.ico?1619448608
2024-03-16T03:50:32Z
やること
Redmine
mikutter - バグ #1597 (実装待ち): mastodon の public/unlisted/privete/direct のアイコンファイル名を参照しているプラグインがある
https://dev.mikutter.hachune.net/issues/1597
2024-03-16T03:50:32Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p><a class="changeset" title="リファクタリング refs #1575" href="https://dev.mikutter.hachune.net/projects/mikutter/repository/main/revisions/a860fae8667de5cade577287066e421a075872ce">a860fae</a> の <a class="source" href="https://dev.mikutter.hachune.net/projects/mikutter/repository/main/revisions/a860fae/entry/plugin/mastodon_gtk/subparts_status_info.rb">source:plugin/mastodon_gtk/subparts_status_info.rb@a860fae</a> 他の変更で<br />mastodon の public/unlisted/private/direct のアイコンファイルが変更されたため、<br />それらのファイル名を直接指定していたプラグインでアイコン表示ができなくなっています。</p>
<p>具体的にはしばふ氏の mastodon_postbox_visibility<br /><a class="external" href="https://github.com/shibafu528/mikutter_mastodon_postbox_visibility/blob/c0c3b15/mastodon_postbox_visibility.rb#L141-L145">https://github.com/shibafu528/mikutter_mastodon_postbox_visibility/blob/c0c3b15/mastodon_postbox_visibility.rb#L141-L145</a><br />で直接参照していて、 <a class="changeset" title="リファクタリング refs #1575" href="https://dev.mikutter.hachune.net/projects/mikutter/repository/main/revisions/a860fae8667de5cade577287066e421a075872ce">a860fae</a> 以降だと少なくとも private と direct のアイコンが error になります。</p>
<p>ただ、これをどう対処するのが正しいのか(mikutter側で互換を残すのか、プラグイン側を直すのか)がよくわかりません。</p>
<pre><code class="ruby syntaxhl"> <span class="vi">@icons</span> <span class="o">=</span> <span class="p">{</span>
<span class="ss">default: </span><span class="s1">'visibility-default.png'</span><span class="p">,</span>
<span class="ss">public: </span><span class="s1">'etc.png'</span><span class="p">,</span>
<span class="ss">unlisted: </span><span class="s1">'unlisted.png'</span><span class="p">,</span>
<span class="ss">private: </span><span class="s1">'private.png'</span><span class="p">,</span>
<span class="ss">direct: </span><span class="s1">'direct.png'</span><span class="p">,</span>
<span class="p">}.</span><span class="nf">freeze</span>
</code></pre>
mikutter - 提案 #1581 (分類待ち): Color Model
https://dev.mikutter.hachune.net/issues/1581
2022-01-16T03:51:58Z
toshi_a 初音
toshi.alternative@gmail.com
<p>mikutter上で色を表現するデータオブジェクトを標準提供する。</p>
<a name="やりたいこと"></a>
<h1 >やりたいこと<a href="#やりたいこと" class="wiki-anchor">¶</a></h1>
現在、色情報を利用する場面は以下のとおりだが、色の表現方法が異なる:
<table>
<tr>
<th>名前</th>
<th>形式</th>
<th>値の範囲</th>
</tr>
<tr>
<td> UserConfig </td>
<td> RGB </td>
<td> 0..0xffff </td>
</tr>
<tr>
<td> Cairo::Color::RGB </td>
<td> RGBA </td>
<td> 0..1 (Float) </td>
</tr>
<tr>
<td> Gtk::Color </td>
<td> RGB </td>
<td> 0..0xffff </td>
</tr>
<tr>
<td> Gdk::RGBA </td>
<td> RGBA </td>
<td> 0..1 (Float) </td>
</tr>
<tr>
<td> CSS </td>
<td> RGB </td>
<td> 0..0xff </td>
</tr>
</table>
<p>現状だと、色をどこで利用するかによって適切に変換しなければならない。<br />異なるクラスなのは仕方ないにしても、UserConfigからCairoに変換するために、各要素を0xffffで割るみたいな処理を毎回実装しなければならない。</p>
<p>レンダリングを行う層以外ではそういった詳細には立ち入りたくないし、現にGtk3移行のときに変換処理がバグっていたことがあった。</p>
<p>mikutterプラグインの共通の色の表現があると、こういった問題を解決できる。</p>
<a name="インターフェイス"></a>
<h1 >インターフェイス<a href="#インターフェイス" class="wiki-anchor">¶</a></h1>
<p>RGBAの要素のみを要求する。<br />精度は、各要素を8bitで返すインターフェイスと、0-1のFloatやRationalで返すインターフェイスが考えられる。<br />アルファブレンド値自体は、無いと困るケースがあるので、このデータオブジェクトで表現に対応する。</p>
<p>ディスプレイは1677万色の表現能力しか持っておらず、24bit (0-255)で十分表現できる。したがって、現在採用しているほとんどの表現形式が過剰である。<br />また、これは人間の識別精度を十分超えているらしく、mikutterのユーザは今のところ地球人のみであると考えているので、これ以上の精度は不要である。</p>
<p>以上のことから、各8bitでも十分である。</p>
<p>一方で、0-1で表現すると、計算が楽で、何をやっているのかわかりやすいというメリットがある。<br /><pre><code class="c++ syntaxhl"><span class="kt">uint16_t</span> <span class="nf">conv</span><span class="p">(</span><span class="kt">uint8_t</span> <span class="n">c</span><span class="p">)</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">c</span> <span class="o">*</span> <span class="mh">0x101</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">uint16_t</span> <span class="nf">conv</span><span class="p">(</span><span class="kt">float</span> <span class="n">c</span><span class="p">)</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">c</span> <span class="o">*</span> <span class="mh">0xffff</span><span class="p">;</span>
<span class="p">}</span>
</code></pre><br />ん〜どうしよっかな〜</p>
<a name="永続化について"></a>
<h1 >永続化について<a href="#永続化について" class="wiki-anchor">¶</a></h1>
<p>UserConfigは古いバージョンとの互換性のために現在の形式を維持しなければならない。</p>
<a name="表現"></a>
<h1 >表現<a href="#表現" class="wiki-anchor">¶</a></h1>
<p>各データクラスは、異なる方法でデータを保持するが、同じインターフェイスを持っている。</p>
<p>TrueColor (32bit color)<br /><pre><code class="ruby syntaxhl"><span class="no">Color</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mi">255</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
<span class="no">Color</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mi">255</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
<span class="no">Color</span><span class="p">.</span><span class="nf">parse</span><span class="p">(</span><span class="s1">'#FF0000'</span><span class="p">)</span> <span class="c1"># red</span>
</code></pre></p>
<p>ContinuouslyColor<br /><pre><code class="ruby syntaxhl"><span class="no">ContinuouslyColor</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mf">1.0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
<span class="no">ContinuouslyColor</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mf">1.0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
</code></pre><br />同じインターフェイスを実装しColor Modelの要件を満たす独自の実装をプラグインが行うことによって、mikutterの色の表現方法を拡張できるように注意する。</p>
<a name="操作"></a>
<h1 >操作<a href="#操作" class="wiki-anchor">¶</a></h1>
<p>spellを使った場合、結果は必ずPromiseを受け取ることになる。色の操作はリアルタイム性が求められることが多く、spellは不適切である。<br />よくありそうな操作についてはColor Pluginで用意する。</p>
<a name="UserConfigの読み込み書き出し"></a>
<h2 >UserConfigの読み込み、書き出し<a href="#UserConfigの読み込み書き出し" class="wiki-anchor">¶</a></h2>
<p>RGBAの各要素は同じ方法で取得できるため、UserConfigに書き出せるはず。<br />現実的には、今の所UserConfigはあらゆるModelを永続化するような機能はもっていないため、別のところに変換ルーチンを実装しなければならない。<br /><pre><code class="ruby syntaxhl"><span class="n">c</span> <span class="o">=</span> <span class="no">Plugin</span><span class="o">::</span><span class="no">Color</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mi">255</span><span class="p">,</span> <span class="mi">255</span><span class="p">,</span> <span class="mi">255</span><span class="p">)</span>
<span class="no">UserConfig</span><span class="p">[</span><span class="ss">:color</span><span class="p">]</span> <span class="o">=</span> <span class="n">c</span> <span class="c1"># 理想</span>
<span class="no">UserConfig</span><span class="p">[</span><span class="ss">:color</span><span class="p">]</span> <span class="o">=</span> <span class="no">Color</span><span class="p">.</span><span class="nf">export_to_user_config</span><span class="p">(</span><span class="n">c</span><span class="p">)</span> <span class="c1"># 現実</span>
</code></pre><br />一方、読み込みはColor Modelだったらどんなものに復元しても良いため、もう少し直接的になりそう。<br /><pre><code class="ruby syntaxhl"><span class="n">c</span> <span class="o">=</span> <span class="no">UserConfig</span><span class="p">[</span><span class="ss">:color</span><span class="p">]</span> <span class="c1"># 理想</span>
<span class="no">Plugin</span><span class="o">::</span><span class="no">UserConfigColor</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="ss">:color</span><span class="p">)</span> <span class="c1"># こういうのがあってもよい?</span>
</code></pre></p>
<a name="印字変換"></a>
<h2 >印字、変換<a href="#印字変換" class="wiki-anchor">¶</a></h2>
<p>例えばHTML形式で印字したいなど。すべてのColor Modelに実装を要求すると印字形式が拡張できないが、インターフェイスが統一されているのでどうとでもなる。<br /><pre><code class="ruby syntaxhl"><span class="k">def</span> <span class="nf">html_color</span><span class="p">(</span><span class="n">color</span><span class="p">)</span>
<span class="s1">'#%02f%02f%02f'</span><span class="p">.</span><span class="nf">format</span><span class="p">(</span><span class="n">color</span><span class="p">.</span><span class="nf">r</span><span class="p">,</span> <span class="n">color</span><span class="p">.</span><span class="nf">g</span><span class="p">,</span> <span class="n">color</span><span class="p">.</span><span class="nf">b</span><span class="p">)</span>
<span class="k">end</span>
</code></pre><br />Cairo::Colorに変換するといった処理は、gtk3プラグインなどが各々提供する。<br /><pre><code class="ruby syntaxhl"><span class="no">Plugin</span><span class="o">::</span><span class="no">Gtk3</span><span class="p">.</span><span class="nf">cairo_color</span><span class="p">(</span><span class="n">c</span><span class="p">)</span>
</code></pre></p>
<a name="比較"></a>
<h2 >比較<a href="#比較" class="wiki-anchor">¶</a></h2>
<p>==で比較する場合、RGBA各要素を0-255で表現した値が等しければ等しいとする。<br />Color Modelインターフェイスの精度以上で比較する意味がないからである。</p>
<p>同様に、eql?とhashもすべてのColorModelが同じ計算式で値を算出しなければならない。</p>
<p>大小比較は、多分ソートすることがないので別にいいや</p>
<a name="標準色"></a>
<h2 >標準色<a href="#標準色" class="wiki-anchor">¶</a></h2>
<pre><code class="ruby syntaxhl"><span class="n">c</span> <span class="o">=</span> <span class="no">Plugin</span><span class="o">::</span><span class="no">Color</span><span class="o">::</span><span class="no">RED</span>
</code></pre>
<p>16色とか256色とか用意する。</p>
<a name="備考"></a>
<h1 >備考<a href="#備考" class="wiki-anchor">¶</a></h1>
<p><a href="https://github.com/red-data-tools/red-colors" class="external">red-colros gem</a> は採用しない。<br />目的に対してできることが多すぎるため。<br />あと、色に対する複雑な演算をしたいわけじゃないので、その程度の理由で直接依存を増やしたくない。</p>
<p>Diva::Modelのatomic typeとして追加することも考えたが、wellknownではあるけどatomicではないかな</p>
mikutter - 提案 #1565 (分類待ち): mastodon_restプラグインとmastodon_sse_streamingプラグインの統合
https://dev.mikutter.hachune.net/issues/1565
2021-12-31T09:21:54Z
toshi_a 初音
toshi.alternative@gmail.com
<p><a class="issue tracker-12 status-5 priority-4 priority-default closed" title="提案: 起動時、直近のリプライが読み込まれない (終了)" href="https://dev.mikutter.hachune.net/issues/1427">#1427</a> の派生タスク。<br />この2つのプラグインは、Mastodonからデータを取ってきてデータソースの更新やイベントの発行を行っている。<br />データソースを使うとき、データの取得方法には関心がないので、別々に制御する必要がない。<br />mastodon_sse_streamingのAPI接続の方法としてREST APIの定期アクセスを実装すればシンプルに収まりそうなので、統合を検討してみる。</p>
mikutter - バグ #1509 (まだダメ): プロフィール: ヘッダウィジェットの横幅よりMiraclePainterの横幅が短くならない
https://dev.mikutter.hachune.net/issues/1509
2021-10-09T07:15:00Z
toshi_a 初音
toshi.alternative@gmail.com
<p>異様にドメイン名が長いサーバの場合、プロフィールのヘッダの横幅の最小サイズが、ウィンドウより大きくなる場合がある。<br />それによって、ListBoxが影響を受け、MiraclePainterが見切れてしまう。</p>
<p>対応方法としては、ヘッダウィジェットの表の右側については自動改行させるのが良さそう。</p>
mikutter for Android - バグ #1488 (マージ待ち): jcenterの依存をやめる
https://dev.mikutter.hachune.net/issues/1488
2021-04-27T10:37:38Z
あひる 家鴨
<p>バグではないけどトラッカーにバグしかないのでバグです!</p>
<p>jcenterのサポートとサービスが終了することが発表されたため、jcenterから移行する必要があります。<br /><a class="external" href="https://developer.android.com/studio/build/jcenter-migration?hl=JA">https://developer.android.com/studio/build/jcenter-migration?hl=JA</a></p>
mikutter - 提案 #1439 (分類待ち): イベントリスナーを一括で有効・無効にする機能
https://dev.mikutter.hachune.net/issues/1439
2020-03-18T15:23:44Z
toshi_a 初音
toshi.alternative@gmail.com
<p>ストリーミングAPI設定など、特定の条件下でのみ有効になるイベントハンドラ(on_*, filter_*, subscribe, collection, generate)のまとまりを定義したい。</p>
<a name="原案A"></a>
<h1 >原案A<a href="#原案A" class="wiki-anchor">¶</a></h1>
<pre><code class="ruby syntaxhl"><span class="n">userconfig_if</span><span class="p">(</span><span class="ss">:streaming_enable</span><span class="p">)</span> <span class="k">do</span>
<span class="n">subscribe</span><span class="p">(</span><span class="ss">:event</span><span class="p">)</span> <span class="o">...</span>
<span class="n">on_event</span> <span class="o">...</span>
<span class="k">end</span>
</code></pre>
<p><code>UserConfig[:streaming_enable]</code> がfalse→trueになったときにブロックを一度実行。ブロック内で定義されたハンドラに専用のタグを付けておく。<br />false→trueになったとき、そのタグを持ったハンドラを全てdetachする。</p>
<a name="原案B"></a>
<h1 >原案B<a href="#原案B" class="wiki-anchor">¶</a></h1>
<pre><code class="ruby syntaxhl"><span class="n">sw</span> <span class="o">=</span> <span class="n">switch</span> <span class="k">do</span>
<span class="n">subscribe</span><span class="p">(</span><span class="ss">:event</span><span class="p">)</span> <span class="o">...</span>
<span class="n">on_event</span> <span class="o">...</span>
<span class="k">end</span>
<span class="n">on_userconfig_modify</span> <span class="k">do</span> <span class="o">|</span><span class="nb">name</span><span class="p">,</span> <span class="n">val</span><span class="o">|</span>
<span class="n">val</span> <span class="p">?</span> <span class="n">sw</span><span class="p">.</span><span class="nf">on</span> <span class="p">:</span> <span class="n">sw</span><span class="p">.</span><span class="nf">off</span>
<span class="k">end</span>
</code></pre>
<p>汎用的なもの。onとoffメソッドは冪等に振る舞う。</p>
<a name="原案C"></a>
<h1 >原案C<a href="#原案C" class="wiki-anchor">¶</a></h1>
<pre><code class="ruby syntaxhl"><span class="n">tag</span> <span class="o">=</span> <span class="n">handler_tag</span> <span class="k">do</span>
<span class="n">subscribe</span><span class="p">(</span><span class="ss">:event</span><span class="p">)</span> <span class="o">...</span>
<span class="n">on_event</span> <span class="o">...</span>
<span class="k">end</span>
<span class="n">on_userconfig_modify</span> <span class="k">do</span> <span class="o">|</span><span class="nb">name</span><span class="p">,</span> <span class="n">val</span><span class="o">|</span>
<span class="n">val</span> <span class="p">?</span> <span class="n">tag</span><span class="p">.</span><span class="nf">enable</span> <span class="p">:</span> <span class="n">tag</span><span class="p">.</span><span class="nf">disable</span>
<span class="k">end</span>
</code></pre>
<p>原案Bを、既存機能であるhandler_tagに有効化/無効化オプションを付けて実現するもの。<br />ブロックはその中で定義されたハンドラにタグを付与するだけなので、</p>
<p>タグがついているものに有効フラグがつくのはわかりやすいが、ネストされた場合は有効フラグのANDを取りたいので、タグ機能とは相性が悪いかもしれない。</p>
mikutter - 提案 #1426 (実装待ち): ユーザープロフィールタブのリアルタイム更新
https://dev.mikutter.hachune.net/issues/1426
2020-01-07T12:16:21Z
toshi_a 初音
toshi.alternative@gmail.com
<a class="issue tracker-12 status-2 priority-4 priority-default" title="提案: mastodon プラグインに追加したい機能 (実装待ち)" href="https://dev.mikutter.hachune.net/issues/1424">#1424</a> より
<ul>
<li>現状はタブを開いた時のTLからは更新されない</li>
<li>各受信トゥートのデータソースの扱いの問題だとすると結構大変かもしれませんが。</li>
</ul>
mikutter - 提案 #1424 (実装待ち): mastodon プラグインに追加したい機能
https://dev.mikutter.hachune.net/issues/1424
2020-01-04T18:02:00Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>以前 slack や KOF で話が出ていて、 2020/1/4 のてオフで再度話が挙がって<br />「チケットに書いておいて欲しい」とのことだったので、<br />パッチなしですが提案チケットとして記載します。</p>
<a name="mastodon-プラグインで実現したいこと"></a>
<h3 >mastodon プラグインで実現したいこと<a href="#mastodon-プラグインで実現したいこと" class="wiki-anchor">¶</a></h3>
Twitter プラグインではできていて、現状の mastodon プラグインでできていない以下:
<ul>
<li>ユーザープロフィールタブ内のユーザーTLタブの表示について、<br />そのユーザーの新たなトゥートを受信したらユーザーTLタブにも追加する
<ul>
<li>現状はタブを開いた時のTLからは更新されない</li>
<li>各受信トゥートのデータソースの扱いの問題だとすると結構大変かもしれませんが。</li>
</ul>
</li>
<li>mikutter 起動時に、mastodon の reply タブに起動時点から過去に遡って一定数のリプライを表示する
<ul>
<li>TwitterだとAPIがそういう仕様だったということかもしれませんが、<br />現状の mastdon plugin では起動以降のリプライのみの表示<br />(ただし、Twitter APIも今は「過去xx個のリプライ」ではなく「過去N日間のリプライ」に変わっている気がする)</li>
</ul>
</li>
<li>ユーザープロフィールタブを再起動時に復元する
<ul>
<li>ユーザープロフィールタブ内のタブの並び順は復元されますが、<br />ユーザープロフィールタブ自体は再起動時復元されないと思います</li>
</ul></li>
</ul>
<a name="mastodon-プラグインの動作で確認したいこと"></a>
<h3 >mastodon プラグインの動作で確認したいこと<a href="#mastodon-プラグインの動作で確認したいこと" class="wiki-anchor">¶</a></h3>
<ul>
<li>mikutter 起動時、 mastodon の HTL にトゥートが一定数表示されるが、<br />これが「起動時から一定数遡ったトゥート」ではなく、飛び飛びのトゥートになっている(ような気がする)</li>
</ul>
<a name="忘れていること"></a>
<h3 >忘れていること<a href="#忘れていること" class="wiki-anchor">¶</a></h3>
<p>思い出したらまた書き足します。</p>
mikutter - 提案 #1411 (toshi_aの判断待ち): streaming_connection_status プラグインをGitHubにアップロードしてほしい
https://dev.mikutter.hachune.net/issues/1411
2019-12-22T10:27:46Z
Shibafu Midorino
<p>どうせFilterStreamでしか使い道はないのですが、エラーを確認する手段として一応どこかに残っていてほしいなと思ってのリクエストです。</p>
mikutter - 提案 #1352 (実装待ち): 詳細な投稿内容の編集ができる、投稿タブを表示するプラグイン
https://dev.mikutter.hachune.net/issues/1352
2019-06-22T08:14:38Z
toshi_a 初音
toshi.alternative@gmail.com
<a name="解決したい問題"></a>
<h1 >解決したい問題<a href="#解決したい問題" class="wiki-anchor">¶</a></h1>
<p>現在のPostboxは、Twitterが短いテキストを投稿するサービスだった頃に設計されているため、テキスト入力エリアしかない。<br />Mastodonなどの別のWorldではこの前提は成り立たず、MastodonのWebでの投稿は以下のようなUIになっている。</p>
<p><img src="https://dev.mikutter.hachune.net/attachments/download/596/a.png" title="MastodonのWeb投稿インターフェイス" alt="MastodonのWeb投稿インターフェイス" /></p>
<p>また、Twitterも、現在は画像添付ができるなど、単純なテキスト投稿サイトではなくなっているどころか、そうだった頃のことを誰も覚えていないと思われるため、今の仕様は時代に即していない。</p>
<a name="方法"></a>
<h1 >方法<a href="#方法" class="wiki-anchor">¶</a></h1>
<p>前述の事情はあるにせよ、現在のPostboxの仕様は、疾く投稿できるうえ、ほとんど場合ニーズを満たしているので、廃止しない。<br />全く別の投稿作成インターフェイスを新しく作り、ユーザが都度使いたい方を使うという方針で一旦考える。</p>
<p>現在のQuickStepのように、Windowロールのコマンドとして投稿作成を呼び出せるようにする。<br />これを呼び出すと投稿タブを作成し、指定された方法で指定された入力項目を入力できるウィジェットを並べる。</p>
<p>投稿するWorldは、投稿タブを開いた時のCurrent Worldとする。開いた後にCurrent Worldを変更しても反映しない。Worldによって求められる入力項目は異なるし、同じWorldでも、アカウントによって入力できる項目が異なるかもしれない(権限の違いなど)。</p>
<p>入力項目の指定はプラグインDSLで行う。例えば以下のような感じを想定している。</p>
<pre><code class="ruby syntaxhl"><span class="n">compose</span><span class="p">(</span><span class="ss">:mastodon</span><span class="p">)</span> <span class="k">do</span>
<span class="n">multitext</span> <span class="s2">"CW警告文"</span><span class="p">,</span> <span class="ss">:spoiler_text</span>
<span class="n">postbox</span>
<span class="nb">select</span> <span class="s2">"公開範囲"</span><span class="p">,</span> <span class="ss">:visibility</span> <span class="k">do</span>
<span class="n">option</span> <span class="ss">:public</span><span class="p">,</span> <span class="s2">"公開"</span>
<span class="n">option</span> <span class="ss">:unlisted</span><span class="p">,</span> <span class="s2">"未収載"</span>
<span class="n">option</span> <span class="ss">:private</span><span class="p">,</span> <span class="s2">"非公開"</span>
<span class="n">option</span> <span class="ss">:direct</span><span class="p">,</span> <span class="s2">"ダイレクト"</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre>
<p>FormDSLに加えて、Postboxと同等の入力インターフェイスをもつテキスト領域を表示する <code>postbox</code> のようなメソッドを用意する。</p>
<ul>
<li>ユーザがPostboxで入力中に、やっぱりファイルも添付したいと思った時に、本文を引き継いて投稿タブを開ける可能性がある</li>
<li>Postboxの文字数カウントがこちらでも利用できる</li>
<li>postboxロールのmikutterコマンドを使える可能性がある</li>
</ul>
<p>Formの値はcompose spellにそのまま渡されるようにしておく。引数の解釈はcompose spellのほうでよしなにできるはずだが、この投稿タブDSLとcompose spellとWorldはそれぞれ別のプラグインで提供できるため、Spellに渡す前に値を変換できるレイヤーがあっても良いかも。</p>
<p>リプライも同時に実装できそう。</p>
mikutter - 最適化 #1315 (新規): filterの戻り値を加工しない場合、配列よりもアロケートのコストが軽いオブジェクトで代用する
https://dev.mikutter.hachune.net/issues/1315
2019-02-09T17:41:29Z
toshi_a 初音
toshi.alternative@gmail.com
<a name="動機"></a>
<h1 >動機<a href="#動機" class="wiki-anchor">¶</a></h1>
<p>メモリプロファイルを取ったところ、以下のようなコードで作成される配列が大量にあった。フィルタを過剰に呼び出さない工夫も必要だが、大抵のフィルタは値を加工しないので、値を加工しなかったことを示すキーワードを代わりに返すことで、ほとんどのフィルタ呼び出しで配列の作成を1回削減できる。</p>
<a name="対応"></a>
<h1 >対応<a href="#対応" class="wiki-anchor">¶</a></h1>
<p>値を加工しなかったことを示す値には以下の候補がある:</p>
<p>- <code>nil</code> : やりやすいが見慣れていないと何のことかわからない<br />- <strong>何らかのSymbolや定数:</strong> オブジェクトを作成しない。意図が明確になる。<br />- <strong>何らかのメソッド:</strong> 今もフィルタを強制的にキャンセルするために <code>Filter.cancel</code> とか書いてるので、 <code>Filter.pass</code> とか書いたら帯域脱出した上でパスできると良いかも。<br />- <strong>filter_xxxの引数に加工しないという宣言を与える:</strong> 戻り値が偶然衝突することはないが融通は効かない</p>
mikutter - 提案 #1255 (実装待ち): Worldの選択を保持する
https://dev.mikutter.hachune.net/issues/1255
2018-05-27T10:52:42Z
Yuto Tokunaga
yuntan.sub1@gmail.com
<p>起動時に前回の終了時に選択していたWorldを復元する機能の提案です.</p>
mikutter - 最適化 #1158 (新規): ret_nthユーティリティの利用をやめる
https://dev.mikutter.hachune.net/issues/1158
2018-01-23T02:30:11Z
toshi_a 初音
toshi.alternative@gmail.com
<p><a class="source" href="https://dev.mikutter.hachune.net/projects/mikutter/repository/main/entry/core/utils.rb#L45">source:core/utils.rb#L45</a> には、ret_nthという、n番目の引数を返すProcを返すメソッドがある。<br />標準プラグインでは0番目を指定することで恒等関数のような用途にしか使われていない。</p>
<p>恒等関数であれば、Ruby 2.2からは <code>Object#itself</code> が標準で用意されている。mikutter 3.6ではRuby 2.3以降をサポートするとしているので、 <code>Object#itself</code> を使い、ret_nthの利用を避ける。もしret_nthの利用を全てやめることができたら、ret_nthをdeprecateにすることも検討する。</p>
mikutter - 最適化 #800 (新規): ユーザの鍵アイコンが毎回ストレージからロードされている
https://dev.mikutter.hachune.net/issues/800
2015-12-21T19:09:19Z
toshi_a 初音
toshi.alternative@gmail.com
<p>これ多分Pixbuf使いまわして問題なかったはずだし、そもそも使い回されてると思っていた。ブランチ変えて画像なくなったら読み込みエラーの画像になってしまうので、毎回ロードしているのでは?</p>
mikutter - 提案 #17 (分類待ち): フィルタ条件設定ウィジェットにテスト機能をつける
https://dev.mikutter.hachune.net/issues/17
2010-12-23T09:28:04Z
toshi_a 初音
toshi.alternative@gmail.com
<p>そのフィルタ条件が期待したとおりに動作するかどうかをテストするための機能をもたせる。<br />具体的には、サブフィルタ(条件の集合)ごとに、その下部に「テスト」ボタンを付け、クリックするとタイムラインを含んだポップアップウィンドウを出す。なんらかの方法で選び出されたメッセージ一つひとつに、フィルタの条件に合致したか否かをバッジなどで表示する。<br />タイムラインウィジェットは処理が重いし、そこからリプライなどは必要ないので、リストビューを使うことも検討したほうがいいかも知れない。</p>