mikutter

GTK2 miracle painter だと 機能 #148: スクロールロック機能 の e807e810 で明示的実装により対応されているっぽい。

ただ、 GTK2の miracle painter は Gtk::TreeView だったが
GTK3 の miracle painter は #1399#note-4 のとおり Gtk::ListBoxRow および Gtk::ListBox で、
e807e810 をチラ見すると Gtk::TreeView べったりという感じ？

そもそも考え方として共通部分があるかどうかは見てみないとわからない、というところからか。

コンセプト雑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 という概念が無さそうなので
見えてなくても描画演算が動かざるを得ない、と言われたらそうなのかも。