From f3098daeb4ee806649d9bddfde195b34f1da0f79 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 4 Jan 2023 23:55:21 +0100 Subject: [PATCH] Timeline: investigate problem with horizontal scrollbar As it turns out, this happens as side-effect from the workaround 2019-08-22 fc5eaf857c687d769df22d6f98a25e8e359e7c49 Obviously, just set_size() on the canvas is not sufficient for GTK actually to establish a size-request (seemingly the canvas counts as /empty/ and only real widgets would make a difference). However, since the ruler canvas is directly placed into the box, and not adapted by a ScrolledWindow, explicitly set_size_request() also causes the enclosing Box to "inherit" this minimal required size, thereby also spreading out the BodyCanvasWidget beyond the size actually available. GTK handles this situation by hard-clipping on the right side, which causes the vertical scrollbar to disappear and keeps the horizontal scrollbar disabled (since nominally it still spans the whole size available, even while this size is then clipped subsequently). This changeset adds a lot of debug printing and demonstrates this behaviour by setting only a minimal horizontal size_request, so that the window is no longer expanded and clipped. --- src/stage/timeline/body-canvas-widget.cpp | 29 ++- src/stage/timeline/body-canvas-widget.hpp | 1 + src/stage/timeline/timeline-layout.cpp | 5 +- wiki/thinkPad.ichthyo.mm | 279 +++++++++++++++++++++- 4 files changed, 299 insertions(+), 15 deletions(-) diff --git a/src/stage/timeline/body-canvas-widget.cpp b/src/stage/timeline/body-canvas-widget.cpp index 8897e4dc2..207bb8bb8 100644 --- a/src/stage/timeline/body-canvas-widget.cpp +++ b/src/stage/timeline/body-canvas-widget.cpp @@ -52,7 +52,7 @@ //#include "stage/ui-bus.hpp" //#include "lib/format-string.hpp" -//#include "lib/format-cout.hpp" +#include "lib/format-cout.hpp"//////////////TODO #include "common/advice.hpp" #include "lib/util.hpp" @@ -88,7 +88,7 @@ namespace timeline { const int INITIAL_TIMERULER_HEIGHT_px = 30; const int INITIAL_CONTENT_HEIGHT_px = 100; - const int INITIAL_CONTENT_WIDTH_px = 200; + const int MINIMAL_CONTENT_WIDTH_px = 100; /** request a pre-defined CSS style context for the track body */ lumiera::advice::Request trackBodyStyle{"style(trackBody)"}; @@ -444,7 +444,7 @@ namespace timeline { }; // initially set up some dummy space. Will be updated to match on first draw() call... - adjustCanvasSize(INITIAL_CONTENT_WIDTH_px, INITIAL_CONTENT_HEIGHT_px, INITIAL_TIMERULER_HEIGHT_px); + adjustCanvasSize(MINIMAL_CONTENT_WIDTH_px, INITIAL_CONTENT_HEIGHT_px, INITIAL_TIMERULER_HEIGHT_px); this->set_border_width (0); this->property_expand() = true; // dynamically grab any available additional space @@ -517,9 +517,23 @@ namespace timeline { BodyCanvasWidget::getEffectiveHorizontalSize() const { int widthForDebug = contentArea_.get_allocated_width(); + Gtk::Allocation allo; + int basi{0}; + contentArea_.get_allocated_size(allo,basi); + int alloW = allo.get_width(); + auto hadj = contentArea_.get_hadjustment(); +cout<<"|?| win::width="<get_upper()<save(); cox->translate(-offH, -offV); +cout<<"|.| trans->"<get_lower()<<"·"<get_upper()<<"("<get_page_size()<<"±"<get_page_increment()<<")"< - + + + @@ -29110,6 +29112,21 @@ + + + + + + + + + + + + + + + @@ -29151,7 +29168,8 @@ - + + @@ -29264,19 +29282,130 @@ - + + + + + + +
    +
  • + die Funktionen zum expliziten Setzen und re-Sizing sind deprecated. +
  • +
  • + eigentlich sollte die Box automatisch auf Größenänderungen der Kind-Elemente reagieren gemäß Flow/Fill-Layout +
  • +
  • + für klassische Widgets wie z.B. Button funktioniert das auch +
  • +
  • + aber auf ein set_size() auf dem Canvas reagiert das Layout anscheinend nicht +
  • +
+ +
+
+

- die Funktionen zum expliziten Setzen und re-Sizing sind deprecated. + Anmerkung 1/2023: seinerzeit habe ich die Mechanik der Layout-Zuteilung noch nicht wirklich verstanden +

+

+ +

+

+ commit fc5eaf857c687d769df22d6f98a25e8e359e7c49 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Thu Aug 22 17:34:32 2019 +0200 +

+

+ +

+

+     Timeline: find a workaround to cause the Box to reflow the rulerCanvas +

+

+     +

+

+     seemingly, the Box with PACK_SHRINK allocates a zero height to the rulerCanvas initally, +

+

+     which is correct at that point, since the widgets are not yet realised. +

+

+     However, when we later set_size() on the rulerCanvas, the enclosing Box should reflow. +

+

+     It does indeed if the child widget is a button or something similar, however, +

+

+     somehow this reflowing does not work when we set_size on the canvas. +

+

+     +

+

+     A workaround is to place a new set_size_request(). +

+

+     +

+

+     TODO: do this more precisely, and only on the rulerCanvas. To the contrary, +

+

+     the mainCanvas is placed into a scolling-pane and thus does not need a size-Request. +

+

+     Moreover, the latter automatically communicates with the hadjustment() / vadjustment() of +

+

+     the enclosing scrollbars. +

+

+ +

+

+ commit 2390385dc50a8504336f5e1fa1a5dc35eca58f2f +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Wed Aug 21 19:13:55 2019 +0200 +

+

+ +

+

+     Timeline: implement function to set the drawing canvas size +

+

+     +

+

+     as can be verified with the debugger, it sets the correct sizes now. +

+

+     And it is called only once (unless the content size actually changes). +

+

+     +

+

+     TODO: however, the visible display of the GTK widgets is not adjusted

-
- @@ -29305,11 +29434,104 @@ - + + + + + + + + + + + +

+ per DUMP-Print verifiziert: Maximalwert der Scrollbar (=hadj) ist identisch mit get_allocated_width +

+ +
+
+
+ + + + + + + + + + + + + + + + + + + +

+ Beispiel: +

+
    +
  • + initial wurde Canvas-Größe auf 852px gesetzt (Debugging Code zieht 100px ab) +
  • +
  • + die Allocation für das BodyCanvasWidget wird minimal 852 +
  • +
  • + wenn man das Fenster (oder den Teiler der Pane) weiter verkleinert, wird trotzdem 852 geliefert ⟹ nach rechts beschnitten +
  • +
+ +
+ +
+
+
+ + + + + + + + + + + + + + + +
    +
  • + zumindest kann man nun das Fenster tatsächlich verkleinern, und dann mit der Scrollbar horizontal den Haupt-Canvas bewegen. +
  • +
  • + aber der Ruler-Canvas scrollt nicht mit +
  • +
  • + und der Anzeige-Zustand der Scrollbar ist bei mouse-over(Scrollbar) nicht richtig synchronisiert; das wird erst korrekt nach einem Focus-loss/gain +
  • +
+ +
+
+
+
+
+
+ + + + @@ -29745,7 +29967,8 @@ - + + @@ -29756,6 +29979,7 @@

+
@@ -66214,7 +66438,8 @@
- + + @@ -66843,6 +67068,32 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -67276,6 +67527,16 @@ + + + + + + + + + +