バグ #1528
未完了
gtk3: TL先頭を表示していない場合でもメッセージ受信でTLがスクロールする
説明
各種 gtk3 チケットが解決してきて mikutter_gtk3 がだいたい実用上問題なく動くようになってきていますが
いざリリースすると「gtk2 時代と違う」と言われそうな挙動をメモるチケットその3です。
#1526 の「TL先頭にメッセージが追加されたときのアニメーション実装」とは逆に、
TLが先頭にない場合にメッセージが追加された場合、
gtk2 版ではTL表示は変化しない動作だったのが、
gtk3 版では追加されたメッセージン分だけTLが下にスクロールする動作になっている
ように見えます。
Twitter本家で不評だった「読んでるのに勝手にスクロールしないで欲しい」という苦言が出そう。
Izumi Tsutsui さんがほぼ3年前に更新
GTK2 miracle painter だと 機能 #148: スクロールロック機能 の e807e810 で明示的実装により対応されているっぽい。
ただ、 GTK2の miracle painter は Gtk::TreeView だったが
GTK3 の miracle painter は #1399#note-4 のとおり Gtk::ListBoxRow および Gtk::ListBox で、
e807e810 をチラ見すると Gtk::TreeView べったりという感じ？
そもそも考え方として共通部分があるかどうかは見てみないとわからない、というところからか。
Izumi Tsutsui さんがほぼ3年前に更新
コンセプト雑diff投棄
diff --git a/plugin/gtk3/widget/timeline.rb b/plugin/gtk3/widget/timeline.rb
index 7424f10e..dc39633d 100644
--- a/plugin/gtk3/widget/timeline.rb
+++ b/plugin/gtk3/widget/timeline.rb
@@ -109,6 +109,11 @@ module Plugin::Gtk3
row.show_all
@listbox.add(row)
@uri_mp_dict[message.uri.to_s] = row
+ notice "@order.(message): #{@order.(message)}"
+ if row == @listbox.get_row_at_index(0)
+ message_height = [row.allocation.height, row.forecast_height].max
+ @listbox.adjustment.value += message_height
+ end
end
end
@listbox.invalidate_sort if update_ordinal
「追加された message が timeline の先頭」の場合に
「 #1498 の予想高さ分だけ adjustment.value を足す」
（≒先頭に追加される message 分の高さがTL表示領域より上に確保されるように表示開始位置座標を増やす）
ということをすると、高さ予想が当たっているときは見かけ上スクロールしないように見えるようにはなる。
- TL先頭ではないがTL表示領域より前（上）に message が追加された場合
- fav/RT/引用等の subparts 描画等で予想高さが外れて追加されたmessageの高さが増えた場合
追加された message がTL表示領域外であっても subparts 高さの演算が走っている？
そもそも Gtk::ListBox + Gtk::ScrolledWindows の組み合わせで visible_range という概念が無さそうなので
見えてなくても描画演算が動かざるを得ない、と言われたらそうなのかも。