diff --git a/src/gui/panel/timeline-panel.cpp b/src/gui/panel/timeline-panel.cpp index e74a88647..5157647fe 100644 --- a/src/gui/panel/timeline-panel.cpp +++ b/src/gui/panel/timeline-panel.cpp @@ -102,9 +102,9 @@ namespace panel { mem_fun(*this, &TimelinePanel::experiment_3)); buttons_.add(button_3_); - button_4_.set_label("kill"); + button_4_.set_label("_grow"); button_4_.set_use_underline(); - button_4_.set_tooltip_markup("Experiment 4:\nkill arbitrary child widget"); + button_4_.set_tooltip_markup("Experiment 4:\nextend arbitrary child widget's text"); button_4_.signal_clicked().connect( mem_fun(*this, &TimelinePanel::experiment_4)); buttons_.add(button_4_); @@ -220,7 +220,10 @@ namespace panel { void TimelinePanel::experiment_4() { - frame_.set_label("Experiment 4..."); + frame_.set_label("Experiment 4... GROW"); + uint selector = rand() % childz_.size(); + ChildEx& toGrow = *childz_[selector]; + toGrow.set_label ("***"+toGrow.get_label()+"***"); } diff --git a/src/gui/panel/timeline-panel.hpp b/src/gui/panel/timeline-panel.hpp index 2a278fe29..69ea9259f 100644 --- a/src/gui/panel/timeline-panel.hpp +++ b/src/gui/panel/timeline-panel.hpp @@ -83,7 +83,7 @@ namespace panel { * 6. bind some further signal(s) to the ~GtkLayout container * 7. hide and re-show a partially and a totally overlapped widget * 8. find a way to move a widget ✔ and delete arbitrary widgets ✔ - * 9. expand an existing widget (text change) + * 9. expand an existing widget (text change) ✔ * 10. build a custom "clip" widget * 11. retrofit all preceding tests to use this "clip" widget */ diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 5f1f65c47..16a55ba73 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).
@@ -2706,6 +2706,8 @@ In order to build a sensible plan for our timeline structure, we need to investi
:** 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
+;expanding widgets
+:works ex expected
;delete child widgets
:is possible by the {{{Container::remove(Widget*)}}} function
:removed child widgets will also removed from display (hidden)
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 3bcd70e95..20f6ac27e 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -9406,9 +9406,10 @@
-
+
+