やること: チケット
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 - バグ #1584 (分類待ち): リプライ時のリプライ元メッセージ表示に対する領域選択が反転表示にならない
https://dev.mikutter.hachune.net/issues/1584
2022-04-03T09:39:12Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>添付動画 <a class="attachment" href="https://dev.mikutter.hachune.net/attachments/798">mikutter-replay-gtk3.mp4</a> のとおりですが、<br />選択部分の文字色が白、背景色はそのままになっているっぽいです。</p>
mikutter - バグ #1541 (分類待ち): gtk3: TLタブを再選択したときにTL表示位置が選択中メッセージ位置に移動してしまう
https://dev.mikutter.hachune.net/issues/1541
2021-11-13T14:22:17Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>gtk3 版ではTLを表示しているタブが一度隠れた後に再選択して表示される場合の動作仕様が変わってしまっているように見えます。</p>
<ul>
<li>(1) タイムラインの一番下までスクロールする</li>
<li>(2) 一番下のメッセージをクリックして選択する</li>
<li>(3) その状態で同じタイムラインの一番上までスクロールする</li>
<li>(4) 同じペインの別のタブをクリックして選択する</li>
<li>(5) 2つ前の(3)で一番上まで戻したタブをクリックして再度選択して表示させる<br /> →なぜか(2)で選択した一番下のメッセージが出る状態までタイムライン表示が下の方に戻っている</li>
</ul>
<p>従来はタブを再選択表示したときには、タブが隠れたときの元の位置が保持されていたような。</p>
mikutter - バグ #1540 (分類待ち): gtk3: TLでメッセージ選択中にTABを押すと次のタブではなく次のメッセージに移動する
https://dev.mikutter.hachune.net/issues/1540
2021-11-10T13:03:43Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>以下のやり取りから</p>
<p><a class="external" href="https://social.mikutter.hachune.net/@tsutsuii/107247395574397992">https://social.mikutter.hachune.net/@tsutsuii/107247395574397992</a></p>
<blockquote>
<p>mikutter_gtk3 で TL 中のメッセージ選択中に TAB を押すと次のメッセージに選択が移動するけど、これ次のペインとかにタブに移動してほしいという気もするな。gtk2 だとどうだったか……</p>
</blockquote>
<p><a class="external" href="https://social.mikutter.hachune.net/@akkiesoft/107247419975830860">https://social.mikutter.hachune.net/@akkiesoft/107247419975830860</a></p>
<blockquote>
<p>TABおすと、TL→タブ次のペインのTL→タブ…→ツールバー→postboxの順にいどうしてた</p>
</blockquote>
mikutter - バグ #1529 (分類待ち): gtk3: タブを右クリックした際のメニューがマウスボタンを離すと消えてしまう
https://dev.mikutter.hachune.net/issues/1529
2021-10-31T13:21:35Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>各種 gtk3 チケットが解決してきて mikutter_gtk3 がだいたい実用上問題なく動くようになってきていますが<br />いざリリースすると「gtk2 時代と違う」と言われそうな挙動をメモるチケットその4です。</p>
<p>各ペインのタブを右クリックした場合の右クリックメニューが<br />クリックしている間しか表示されず、マウスボタンを離すとメニューが消えてしまう。<br />postboxの右クリックメニューは従来どおり右クリックを離してもメニュー表示は残る。</p>
<p>従来は直感的(?)操作どおりで、右ボタンワンクリックでもメニュー表示・選択ができていた。</p>
mikutter - バグ #1528 (分類待ち): gtk3: TL先頭を表示していない場合でもメッセージ受信でTLがスクロールする
https://dev.mikutter.hachune.net/issues/1528
2021-10-31T13:16:15Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>各種 gtk3 チケットが解決してきて mikutter_gtk3 がだいたい実用上問題なく動くようになってきていますが<br />いざリリースすると「gtk2 時代と違う」と言われそうな挙動をメモるチケットその3です。</p>
<p><a class="issue tracker-1 status-13 priority-4 priority-default" title="バグ: gtk3: TL先頭にメッセージが追加されたときのアニメーション実装 (分類待ち)" href="https://dev.mikutter.hachune.net/issues/1526">#1526</a> の「TL先頭にメッセージが追加されたときのアニメーション実装」とは逆に、<br />TLが先頭にない場合にメッセージが追加された場合、<br />gtk2 版ではTL表示は変化しない動作だったのが、<br />gtk3 版では追加されたメッセージン分だけTLが下にスクロールする動作になっている<br />ように見えます。</p>
<p>Twitter本家で不評だった「読んでるのに勝手にスクロールしないで欲しい」という苦言が出そう。</p>
mikutter - バグ #1526 (分類待ち): gtk3: TL先頭にメッセージが追加されたときのアニメーション実装
https://dev.mikutter.hachune.net/issues/1526
2021-10-31T13:09:09Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>各種 gtk3 チケットが解決してきて mikutter_gtk3 がだいたい実用上問題なく動くようになってきていますが<br />いざリリースすると「gtk2 時代と違う」と言われそうな挙動をメモるチケットその1です。</p>
<p>TL先頭で新たなメッセージを受信したとき似、従来は <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="機能: スクロールアニメーションの最適化 (終了)" href="https://dev.mikutter.hachune.net/issues/304">#304</a> の pretty scroll の仕様で<br />アニメーションでニュルニュルとタイムラインにメッセージが追加されていましたが<br />gtk3 では未実装の状態のはず?</p>
<blockquote>
<p>現在のスクロールアニメーションは、だんだん加速するが、処理が重い時の見栄えが悪いので、だんだん減速するように変更する。<br />また、アニメーションの頻度を30fpsに抑える。</p>
</blockquote>
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 - ワークフローに関する質問 #1324 (新規): 「バグ」チケット添付のパッチのレビュータイミング
https://dev.mikutter.hachune.net/issues/1324
2019-03-10T15:45:34Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>mikutter Redmine のワークフローの「<a class="wiki-page" href="https://dev.mikutter.hachune.net/projects/mikutter/wiki/%E3%83%90%E3%82%B0%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E3%81%AE%E9%80%B2%E3%82%81%E6%96%B9">バグチケットの進め方</a>」を見ると以下のように書かれています。</p>
<blockquote>
<p>"しばしば、バグ報告にいきなり修正パッチがついている場合がある。この場合、ステータスは「パッチ適用待ち」にする。" <br />"この遷移は、報告された問題の存在さえ確認できていれば、パッチの良し悪しに関わらず行って良い。パッチ自体の品質については、あとで判断する。"</p>
</blockquote>
<p>しかし「パッチ適用待ち」の状態の説明では以下の記載になっています。</p>
<blockquote>
<p>"このステータスの時にやるべきことは、単にそのパッチをコミットすることである。"</p>
</blockquote>
<p>「パッチ適用待ち」の項が「<a class="wiki-page" href="https://dev.mikutter.hachune.net/projects/mikutter/wiki/%E6%8F%90%E6%A1%88%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E3%81%AE%E9%80%B2%E3%82%81%E6%96%B9">提案チケットの進め方</a>」のワークフローそのままになってしまっているようにも見えますが、<br />「バグ」のチケットの「パッチの品質の判断」はどこで行われるべきでしょうか。</p>
mikutter - ワークフローに関する質問 #1278 (新規): 「提案」のパッチをレビューするタイミング
https://dev.mikutter.hachune.net/issues/1278
2018-07-15T06:40:18Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>「提案」チケットにおいて、提案された機能自体はOKの場合、<br />添付されているパッチの実装をどのタイミングでレビューするか、<br />という課題。</p>
<ul>
<li>とりあえず無条件に「パッチ適用待ち」にしてブランチに入れてしまって、<br />そのブランチ上で動作だけではなくコードもレビューするのか</li>
<li>パッチの中身をレビューしてOK判断してから「パッチ適用待ち」にするのか</li>
</ul>
mikutter - ワークフローに関する質問 #1276 (新規): コミッタの方によるパッチ投稿
https://dev.mikutter.hachune.net/issues/1276
2018-07-14T13:56:13Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p><a class="issue tracker-12 status-5 priority-4 priority-default closed" title="提案: mobile.twitter.comで始まるtweetのperma_linkの引用に対応する (終了)" href="https://dev.mikutter.hachune.net/issues/1269#note-1">#1269#note-1</a> での議論。<br />コミッタからパッチ付きの提案チケットが投稿された場合、<br />誰がどう判断してステータスを進めるべきか。</p>
<blockquote>
<ul>
<li>コミッター+モデレータのメンバーのうち少なくとも 2人がOKと言ったら進める?</li>
<li>slack や mastodon とかでとしぁさんと会話して「いいよ」だったら進めるとか?</li>
<li>最終的に「パッチ適用待ち」にするときにコミッタの判断が入るなら最初は緩くてもいい?</li>
</ul>
</blockquote>
<p><a class="issue tracker-12 status-5 priority-4 priority-default closed" title="提案: mobile.twitter.comで始まるtweetのperma_linkの引用に対応する (終了)" href="https://dev.mikutter.hachune.net/issues/1269#note-2">#1269#note-2</a> のコメントは以下<br />cob odo さんは書きました:</p>
<blockquote>
<p><a class="wiki-page" href="https://dev.mikutter.hachune.net/projects/mikutter/wiki/%E6%8F%90%E6%A1%88%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E3%81%AE%E9%80%B2%E3%82%81%E6%96%B9">提案チケットの進め方</a>によれば、</p>
<blockquote>
<p>ステータス「分類待ち」の場合<br />この場合、モデレータがその提案が妥当なものなのか判断し返信する。<br />妥当でないならばその理由を説明し、ステータスを「却下」に変更する。<br />モデレータがそれを取り込むべきと判断すれば、以下の条件に従って次に進める。</p>
</blockquote>
<p>ということなので、</p>
<blockquote>
<p>このあたりのGOの判断を誰がどうするか</p>
</blockquote>
<p>は、「独断で(もちろん理由は挙げるとして)GO/NO-GOを判断できる権限がモデレータに与えられている」と解釈するのかなーと思いました。<br />そうは言っても判断が微妙な提案はあると思いますし、迷ったら適宜相談という形でいいのではないかと個人的には思います。</p>
<p>「提案」フローについては、単に「こういう機能がほしい」という提案が(非コミッタ・非プログラマ)から出た場合、モデレータがGOの判断をしてもまだパッチは無いので「パッチ適用待ち」にはできなそうだなとは思いました。</p>
</blockquote>
<p>それに対する返信 <a class="issue tracker-12 status-5 priority-4 priority-default closed" title="提案: mobile.twitter.comで始まるtweetのperma_linkの引用に対応する (終了)" href="https://dev.mikutter.hachune.net/issues/1269#note-3">#1269#note-3</a><br />Izumi Tsutsui さんは書きました:</p>
<blockquote>
<p>cob odo さんは書きました:</p>
<blockquote><blockquote>
<p>このあたりのGOの判断を誰がどうするか</p>
</blockquote>
<p>は、「独断で(もちろん理由は挙げるとして)GO/NO-GOを判断できる権限がモデレータに与えられている」と解釈するのかなーと思いました。<br />そうは言っても判断が微妙な提案はあると思いますし、迷ったら適宜相談という形でいいのではないかと個人的には思います。</p>
</blockquote>
<p>仕様としては歓迎するが、実装(コード)はわからん、という場合は迷うんですよね……。(非プログラマのつぶやき)</p>
<p>公開API変更のような互換性で禍根を残すようなものは別として、「やってみてイマイチだったら元に戻せばいい」という程度の変更なら<br />あまり気にせず「コミッタorモデレータのうちひとりがOKと判断すれば進める」というゆるいルールでよいような気はします。</p>
</blockquote>
mikutter - バグ #948 (新規): 3.4.x → 3.5.0 のアップグレード時プロファイルタブが引き継がれない
https://dev.mikutter.hachune.net/issues/948
2016-12-15T17:11:19Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>mikutter 3.4.8 を使っていた環境でマルチペインを使用している時に<br />複数のユーザーのタブを開いた状態でいったん終了して、<br />3.5.0 にアップグレードして再度 mikutter を立ち上げると、<br />プロファイルタブの表示が以下のように崩れます。</p>
<p>~/.mikutter が存在しない状態から 3.4.8 を起動して<br />マルチペイン設定してプロファイルタブを表示して終了する直前の状態<br /><img src="https://dev.mikutter.hachune.net/attachments/download/278/mikutter-3.4.8.png" style="width:400px;" alt="" /></p>
<p>その後 3.5.0-alpha1 に更新して mikutter を再起動した直後の状態<br /><img src="https://dev.mikutter.hachune.net/attachments/download/279/mikutter-3.5.0.png" style="width:400px;" alt="" /></p>
<p>プロファイルタブの名前が user ID (?) からプロファイルページの URL に変わったのが<br />関係していると思いますが、何かしら移行策は取れるもんでしょうか。</p>
mikutter - バグ #938 (新規): マウスオーバーアイコンの表示が消えない場合がある
https://dev.mikutter.hachune.net/issues/938
2016-11-21T16:46:04Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p><a class="issue tracker-2 status-5 priority-4 priority-default closed" title="機能: ふぁぼろうとした瞬間に別ツイートが滑りこんで誤ふぁぼする事故を防ぐ機能 (終了)" href="https://dev.mikutter.hachune.net/issues/888">#888</a> で別件で書いたまま忘れていた件ですが</p>
<p>TLの一番上を表示していて自動スクロールする状態で<br />TLの任意のツイートのアイコン上にマウスカーソルを持って行って<br />マウスオーバーアイコンを表示させた状態で新しいツイートを受信して<br />TL全体が下にスクロールしていった場合に、マウスオーバーアイコンが<br />表示されていたアイコンが下にスクロールしていってマウスカーソルが外れても<br />マウスオーバーアイコンが表示されたままになります。<br />うまく(?)操作するとTLのほぼすべてのツイートにマウスオーバーアイコンが<br />表示されたまま、という状態にもなります。</p>
<p>実害があるわけではありませんが、スクロールの時にマウスのイベントを取る<br />というのは難しいんでしょうか。<br /><img src="https://dev.mikutter.hachune.net/attachments/download/276/P_20160925_151548.jpg" style="width:360px;" alt="" /></p>
mikutter - バグ #736 (新規): 抽出タブのデータソース設定画面でチェックできないチェックボックスがある
https://dev.mikutter.hachune.net/issues/736
2014-12-13T04:01:59Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>設定ウインドウの<br />抽出タブ→(タブを選択)→編集→「データソース」<br />の画面で、 @tsutsuii のような親メニュー(?)のところに<br />チェックできないチェックボックスが表示されます。<br />左の展開ボタンを押した後の下の階層のはチェックできるのですが、<br />チェックボックスの表示に混乱するユーザーもいるようなので<br />表示しないようにしたほうがよいと思います。<br /><a class="external" href="https://twitter.com/ebijun/status/542043878288019456">https://twitter.com/ebijun/status/542043878288019456</a><br /><a class="external" href="https://twitter.com/ebijun/status/542054203825209344">https://twitter.com/ebijun/status/542054203825209344</a></p>
mikutter - バグ #465 (実装待ち): favとRTが両方されているとfavった人アイコンのマウスオーバーでのID表示がされない
https://dev.mikutter.hachune.net/issues/465
2012-05-11T17:11:24Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>ツイート表示下のRTした人アイコンやfavした人アイコンにマウスオーバーすると<br />favstarと同じくツールチップでその人のTwitter IDが表示されるようになっていますが、<br />favとRTとが両方されていて両者が2段でアイコンが表示されている場合、<br />下段のRTアイコンのほうはマウスオーバーでツールチップが表示されますが、<br />上段のfavアイコンのほうはマウスオーバーしてもツールチップが出ません。<br />RTだけ、favだけの場合はそれぞれ表示されます。</p>
<p>0.1の時点で起きていたと思いますが、素の0.1.1.783でも確認しました。</p>