diff --git a/src/gui/panel/timeline-panel.cpp b/src/gui/panel/timeline-panel.cpp index cb7ad529b..3193006f0 100644 --- a/src/gui/panel/timeline-panel.cpp +++ b/src/gui/panel/timeline-panel.cpp @@ -113,7 +113,7 @@ namespace panel { scroller_.set_border_width(10); scroller_.add(canvas_); - canvas_.set_size(1000,500); + adjustToNecessaryCanvasSize(); // show everything.... this->add(twoParts_); @@ -133,6 +133,28 @@ namespace panel { } + void + TimelinePanel::adjustToNecessaryCanvasSize() + { + uint sizeX = 10; + uint sizeY = 10; + for (Widget* chld : childz_) + { + uint x = canvas_.child_property_x(*chld); + uint y = canvas_.child_property_y(*chld); + x += chld->get_allocated_width(); + y += chld->get_allocated_height(); + sizeX = max (sizeX, x); + sizeY = max (sizeY, y); + } + // additional leeway for the scrollbars + sizeX += 10; + sizeY += 10; + + canvas_.set_size (sizeX, sizeY); + } + + void TimelinePanel::experiment_1() { @@ -144,6 +166,7 @@ namespace panel { uint y = rand() % 500; canvas_.put(*chld, x, y); chld->show(); + adjustToNecessaryCanvasSize(); } @@ -162,6 +185,7 @@ namespace panel { canvas_.move (*chld, x,y); } + adjustToNecessaryCanvasSize(); } @@ -178,6 +202,7 @@ namespace panel { int width = chld->get_allocated_width(); pos += 0.6 * width; } + adjustToNecessaryCanvasSize(); } diff --git a/src/gui/panel/timeline-panel.hpp b/src/gui/panel/timeline-panel.hpp index 6e33d8ba3..ccabf2271 100644 --- a/src/gui/panel/timeline-panel.hpp +++ b/src/gui/panel/timeline-panel.hpp @@ -118,6 +118,8 @@ namespace panel { using ChildV = std::vector; ChildV childz_; + void adjustToNecessaryCanvasSize(); + void experiment_1(); void experiment_2(); void experiment_3(); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 406696b00..5f1f65c47 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2635,7 +2635,7 @@ In the most general case, there can be per-track content and nested content at t → important question: how to [[organise the widgets|GuiTimelineWidgetStructure]] -
+
The Timeline is probably the most prominent place in the GUI where we need to come up with a custom UI design.
 Instead of combining standard components in one of the well-known ways, here we need to come up with our own handling solution -- which also means to write one or several custom GTK widgets. Thus the question of layout and screen space division and organisation becomes a crucial design decision. The ~GTK-2 Gui, as implemented currently, did already take some steps along this route, yet this kind of decision should be cast and documented explicitly (be it after the fact).
 
@@ -2690,16 +2690,20 @@ In order to build a sensible plan for our timeline structure, we need to investi
 
 !!!Observations
 * children need to be made visible, otherwise they are added, but remain hidden
-* the size of the scrollable area is independent of the actual size extension of the canvas
-* the scrollable area determines when scrollbars are visible and what area can be reached through them
-* but children can well be placed beyond; they are fully functional then, just covered and out of sight
-* enlarging the enclosing window and thus enlarging the layout canvas will uncover such stray children.
 * when in sight, children receive events and are fully functional, even when placed out of the scrollable area.
 * the coordinate of children is their upper left corner, but they may extend beyond that and even beyond the scrollable area
-* children may be so close to the boundary, that it is not possible to click on them
-* when children close to the boundary receive an onClick event, the scrollable area might jumps back slightly..
 ;layering
 :children added later are always on top.
+;scrolling and size
+:the {{{Gtk::Layout}}} widget has a canvas size, which is defined implicitly, by placing child elements
+:* the size of the scrollable area is independent of the actual size extension of the canvas
+:* the scrollable area determines when scrollbars are visible and what area can be reached through them
+:* but children can well be placed beyond; they are fully functional then, just covered and out of sight
+:* enlarging the enclosing window and thus enlarging the layout canvas will uncover such stray children.
+:* //problematic//
+:** children may be so close to the boundary, that it is not possible to click on them
+:** when children close to the boundary receive an onClick event, the scrollable area might jump back slightly..
+:** the management of visible viewport within {{{Gtk::ScrolledWindow}}} is not correct (see [[ticket #1037|http://issues.lumiera.org/ticket/1037]])<br/>it does not account properly for the area covered by the scrollbars themselves
 ;moving child widgets
 :works as expected
 ;delete child widgets
@@ -2707,7 +2711,7 @@ In order to build a sensible plan for our timeline structure, we need to investi
 :removed child widgets will also removed from display (hidden)
 :but the widget object needs to be deleted manually, because detached widgets are no longer managed by GTK
 ;iteration over child widgets
-:problematic
+://problematic//
 :* the signal based {{{foreach}}} does not work -- there seems to be a problem with the slot's signature causing a wrong address to be passed in
 :* the interface {{{Gtk::Container}}} exposes a {{{get_children}}} function, but this returns a //copy// of the vector with pointers to all child widgets
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 1a33fe7d3..3bcd70e95 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -9386,9 +9386,10 @@ - + +