やること: チケット
https://dev.mikutter.hachune.net/
https://dev.mikutter.hachune.net/favicon.ico?1619448608
2024-03-13T14:16:48Z
やること
Redmine
mikutter - 機能 #1596 (新規): Ruby 3.3
https://dev.mikutter.hachune.net/issues/1596
2024-03-13T14:16:48Z
toshi_a 初音
toshi.alternative@gmail.com
<ul>
<li>Ruby 3.3をサポートする</li>
<li>mikutter 5.1では、Rubyのバージョン下限を3.2.0にする(過去1バージョンのみ対応)</li>
<li>Ruby 3.0, 3.1, 3.2で追加された要素を使ってリファクタリング</li>
</ul>
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 - バグ #1577 (終了): 抽出タブ絞り込み条件で「投稿したクライアントアプリケーション名」に「含む」を設定するとクラッシュする
https://dev.mikutter.hachune.net/issues/1577
2022-01-09T06:48:18Z
toshi_a 初音
toshi.alternative@gmail.com
<p>再現手順の通り実行すると、抽出タブの絞り込みでクラッシュする。<br />Mastodonのstatusはclient情報をもっていない ( <code>nil</code> )ことがある。<br />この抽出条件は<br /><pre><code class="ruby syntaxhl"><span class="n">message</span><span class="p">.</span><span class="nf">client</span><span class="p">.</span><span class="nf">include?</span><span class="p">(</span><span class="s1">'mikutter'</span><span class="p">)</span>
</code></pre><br />のようなコードにコンパイルされる。clientがnilを返す場合も考慮する必要がある。</p>
<p>Twitterでは、すべてのMessageがsourceの戻り値として空文字列を返すようにしていた気がするので再現しないと思う。<br />また、「=」の場合は <code>==</code> で比較されるので、クラッシュしない。</p>
mikutter - 提案 #1575 (終了): rubocopで定めたコーディング規約の適用方針・範囲の決定
https://dev.mikutter.hachune.net/issues/1575
2022-01-08T08:25:24Z
toshi_a 初音
toshi.alternative@gmail.com
<p>将来的にすべてのソースコードがrubocopのlintに合格しないとmergeできないようにして、常にコーディング規約を満たした状態に持っていく。</p>
<a name="方針"></a>
<h1 >方針<a href="#方針" class="wiki-anchor">¶</a></h1>
<p>10年くらい前までやっていた行末endなどのコーディング規約は既に廃止しているが、一気にやるとdiffがえらいことになってblameなどで若干面倒になるので、少しでも編集したメソッドに関してだけ修正していっている。<br />雑に全部auto correctすると、相当なdiffが発生する。diffの量を小さくするため、次のようにファイルを優先度で分類し、やる価値が高いと判断したものにだけ適用する。</p>
1. 優先度低: 何年もの間、全く開発者から参照されず、書き換えられていないファイル
<ul>
<li>古いコードほど今と異なる規約でコーディングされているので、diffが大きくなっていく傾向にある</li>
<li>そもそも誰も読まないので、コーディング規約を守っていても違反していてもあんまり関係がない</li>
<li>diffが大きいことからリグレッションの可能性が相対的に上がり、検証がだるい</li>
</ul>
2. 優先度高: 頻繁に開発者から参照され、書き換えが行われるようなファイル
<ul>
<li>歴史が浅いため、規約を適用しても小さなdiffですむ</li>
<li>書き換えが最近行われているので、直近で開発者が読む可能性が高く、コーディング規約を守る重要性が高い</li>
<li>リグレッションが発生しても、最近修正した機能ならまだ覚えているので、修正が容易</li>
</ul>
<a name="手順"></a>
<h1 >手順<a href="#手順" class="wiki-anchor">¶</a></h1>
<p>一気にやるとdiffがえらいことになってblameなどで若干面倒になるので、新規ファイルや著しい変更があったファイルに限定したい。<br />これを満たすために、rubocop対象のファイルをブラックリスト形式で管理する。ブラックリストは、作成した後は減らすことしかしないため、全体のエラー率は時間の経過とともに下がっていく。</p>
<p>ブラックリストは以下の条件で作成する:</p>
<ul>
<li>mikutter 4.1.0(rubocop導入したひとつ前のバージョン)で存在したすべてのファイル</li>
</ul>
<p>今後、以下の条件を満たすものは即座にブラックリストから削除する:</p>
<ul>
<li>mikutter 4.1.0以降で50%以上の行が変更されたファイル(割合はいろいろ変えて様子を見て決定する)<br /> 大幅にリファクタリングしたファイルなどはどうせdiffがでかくなっていてblameのとき邪魔なので、いっそのこと機械的にやってしまう</li>
</ul>
<a name="このIssueでやること"></a>
<h1 >このIssueでやること<a href="#このIssueでやること" class="wiki-anchor">¶</a></h1>
<ol>
<li>ブラックリストの作成</li>
<li>ブラックリストを除外したファイルのルールを検証する方法の確立</li>
<li>ブラックリストから除外対象となったファイルを除く方法の確立</li>
<li>2を使ってコードをリファクタリングする</li>
</ol>
<p>適用するバージョンは5.0(メンテナンスしている最も古いバージョン)にする。gtk3のコードに適用したいが、そうするとそれなりのdiffが発生してしまい、mergeが困難となることが予想されるため。</p>
<a name="懸念"></a>
<h1 >懸念<a href="#懸念" class="wiki-anchor">¶</a></h1>
<p>開発者が参照するコードは、頻繁に変更もされているはずだという前提に立っているが、なかには長い間変更されていないが参照されるコードというものも存在する。<br />この基準ではそういったコードをフォローできていない。</p>
<a name="他の方法"></a>
<h1 >他の方法<a href="#他の方法" class="wiki-anchor">¶</a></h1>
<p>rubocop todoは、コードの古さに応じてルールの適用方針を変えていく考え方とはあまり相性がよくなさそうなので、利用を断念した。</p>
mikutter - バグ #1574 (終了): TCPコネクションが確立できないときにmastodon_sse_stramingがクラッシュする
https://dev.mikutter.hachune.net/issues/1574
2022-01-02T08:18:12Z
toshi_a 初音
toshi.alternative@gmail.com
<p>mastodon_sse_stramingが、コネクションを切断された | 確立できなかった場合の処理を実装していない。</p>
mikutter - 機能 #1568 (新規): TLのアイコンサイズを変更できるようにしたい
https://dev.mikutter.hachune.net/issues/1568
2021-12-31T14:58:57Z
toshi_a 初音
toshi.alternative@gmail.com
<p><a class="issue tracker-2 status-6 priority-4 priority-default closed" title="機能: TLのアイコンサイズを変更できるようにしたい (却下)" href="https://dev.mikutter.hachune.net/issues/602">#602</a></p>
<p>subpartsではできるのでできないとアンバランスですね</p>
mikutter - 提案 #1567 (終了): commandの「引用」を削除する
https://dev.mikutter.hachune.net/issues/1567
2021-12-31T14:49:05Z
toshi_a 初音
toshi.alternative@gmail.com
<p>非公式リツイート…なにもかもみな懐かしい</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 - 機能 #706 (却下): saved searchをデータソースとして提供する
https://dev.mikutter.hachune.net/issues/706
2014-08-05T01:53:45Z
toshi_a 初音
toshi.alternative@gmail.com
<p>saved searchプラグインは、タブの提供をやめて、抽出タブのデータソースを提供する。</p>
<p>saved searchデータソースは、利用されているときだけ自動更新をかける。<br />不要な検索タブが表示されないようになること、データソースとタブが分離するので、起動時にUI上に空のタブが生成されてしまう問題などを回避できる。</p>
<p>ただし、「保存した検索」を削除する機能をどこかにつけなければいけない。現状ではタブのコマンドになっているが、これは無くなる。</p>
mikutter - 最適化 #564 (終了): ダークマターが潜むプラグインの特定
https://dev.mikutter.hachune.net/issues/564
2013-02-12T15:39:36Z
toshi_a 初音
toshi.alternative@gmail.com
<p>実装しているとメモリリークするプラグインを特定する</p>
<a name="導入済みプラグインの取得方法"></a>
<h1 >導入済みプラグインの取得方法<a href="#導入済みプラグインの取得方法" class="wiki-anchor">¶</a></h1>
<p>以下の方法で導入されているプラグインのインスタンスを取得できる。ただし、現在のdevelopブランチにはバグで「.rb」が末尾についたスラッグのプラグインが生成されてしまう問題があるのでrejectを使う。<br /><pre>
Plugin.instances.reject{ |x| x.to_s.end_with?(".rb") }
</pre></p>
<a name="依存するプラグイン"></a>
<h1 >依存するプラグイン<a href="#依存するプラグイン" class="wiki-anchor">¶</a></h1>
<p>プラグインには依存関係があり、 <strong>親プラグインがロードされないと子プラグインはロードされない</strong> 。必ず --plugin オプションには親プラグインも同時に指定する(「--plugin=home_timeline」は誤り。「--plugin=gui,gtk,home_timeline」とする)。<br />依存関係はspecファイルによってのみ定義されていて、specファイルの内容は以下のようなコードで取得できる<br /><pre>
plugins[0].instance_eval{ @spec }
</pre></p>
<a name="ロードするプラグインを限定する"></a>
<h1 >ロードするプラグインを限定する<a href="#ロードするプラグインを限定する" class="wiki-anchor">¶</a></h1>
<p>特定のプラグインだけロードしたい場合は、「--plugin」オプションでスラッグを指定する。複数のプラグインを指定する場合はカンマで区切る。--pluginを二つ以上指定することはできない。<br /><pre>
./mikutter.rb --plugin="gui,gtk,rest,streaming,home_timeline,memory_profiler" --debug
</pre><br />この方法でプラグインスラッグを指定すると、そのスラッグにマッチしないプラグインはロードされない。</p>
<a name="バージョン"></a>
<h1 >バージョン<a href="#バージョン" class="wiki-anchor">¶</a></h1>
<p>0.2.2(develop ブランチ)の新機能なので、他のバージョンでは計測できない。</p>
<a name="その他"></a>
<h1 >その他<a href="#その他" class="wiki-anchor">¶</a></h1>
<p>ぺんぎんさんがんばれ<br />問題がわかった/わからなかったら、Twitterじゃなくてこっちで教えてください。<br />質問もIRCかこのチケットのコメントにしてください。</p>
mikutter - 最適化 #561 (終了): 大量の実行待ちイベントが発生した時の処理速度の改善
https://dev.mikutter.hachune.net/issues/561
2013-01-23T15:48:52Z
toshi_a 初音
toshi.alternative@gmail.com
<a name="割り込み実行"></a>
<h1 >割り込み実行<a href="#割り込み実行" class="wiki-anchor">¶</a></h1>
<p>現在はDelayerに登録されたブロックは登録された順に実行されているが、大量のイベントがキューイングされるとユーザの入力によって発生するイベントや、GUI関連のイベントの実行が遅れる。<br />この場合でも、ユーザの入力のレスポンスを割り込み実行できれば早くなりそう。</p>
<a name="まとめて実行"></a>
<h1 >まとめて実行<a href="#まとめて実行" class="wiki-anchor">¶</a></h1>
<p>updateイベントなど、複数のデータを一つのデータにまとめられるイベントが大量にキューイングされているなら、それらが別々のプラグインの別々の処理によって発生していたとしても、まとめて単一のイベントにしてしまって良い。<br />Pluginクラスにそのような仕組みを導入できないか検討する。</p>
mikutter - 機能 #448 (却下): 関連ツイートを検出するフィルタ
https://dev.mikutter.hachune.net/issues/448
2012-03-27T17:08:17Z
toshi_a 初音
toshi.alternative@gmail.com
<p>smartthreadを拡張して、スレッドに特定のツイートに関係するツイートを追加することができるフィルタを定義する。</p>
mikutter - バグ #198 (終了): ダークマターの討伐
https://dev.mikutter.hachune.net/issues/198
2011-05-29T16:31:06Z
toshi_a 初音
toshi.alternative@gmail.com
<p>長時間起動していると、際限なくメモリを消費していく。</p>
mikutter - 機能 #120 (終了): ふぁぼりを解除したら、favorited byのところから自分のアイコンを取り除く
https://dev.mikutter.hachune.net/issues/120
2011-04-26T16:24:52Z
toshi_a 初音
toshi.alternative@gmail.com
<p>ふぁぼり解除時に「xx Fav」のアイコンから、自分のアイコンを取り除くようにする。<br />テロ対策のために他のユーザのふぁぼ削除については一切対応しない</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>