diff --git a/src/gui/panel/timeline-panel.cpp b/src/gui/panel/timeline-panel.cpp index 5157647fe..d111efba6 100644 --- a/src/gui/panel/timeline-panel.cpp +++ b/src/gui/panel/timeline-panel.cpp @@ -68,9 +68,6 @@ namespace panel { : Panel(panelManager, dockItem, getTitle(), getStockID()) , twoParts_(Gtk::ORIENTATION_VERTICAL) , buttons_() - , button_1_() - , button_2_() - , button_3_() , frame_("Gtk::Layout Experiments") , scroller_() , canvas_() @@ -115,6 +112,13 @@ namespace panel { button_5_.signal_clicked().connect( mem_fun(*this, &TimelinePanel::experiment_5)); buttons_.add(button_5_); + + toggleDraw_.set_label("draw"); + toggleDraw_.signal_clicked().connect( + [this]() { + canvas_.enableDraw (this->toggleDraw_.get_active()); + }); + buttons_.add(toggleDraw_); //(End)buttons... frame_.add(scroller_); @@ -240,6 +244,29 @@ namespace panel { } + void + Canvas::enableDraw (bool yes) + { + shallDraw_ = yes; + if (shallDraw_) + { + ///TODO invalidate + cout << "DRRRRAW!"< const& cox) + { + if (shallDraw_) + { + cout << "Canvas::on_draw("< const&) override; + }; + + + /** * Dockable panel to hold timeline widget(s). * @todo build the actual implementation, after finishing the investigation @@ -110,9 +128,10 @@ namespace panel { Gtk::Button button_3_; Gtk::Button button_4_; Gtk::Button button_5_; + Gtk::CheckButton toggleDraw_; Gtk::Frame frame_; Gtk::ScrolledWindow scroller_; - Gtk::Layout canvas_; + Canvas canvas_; ChildEx* makeChld(); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 16a55ba73..747f84b9f 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2398,6 +2398,15 @@ On a second thought, the fact that the [[Bus-MObject|BusMO]] is rather void of a :sound mixing desks use list style arrangement, and this has proven to be quite viable, when combined with the ability to //send over// output from one mixer stripe to the input of another, allowing to build arbitrary complex filter matrices. On the other hand, organising a mix in //subgroups// can be considered best practice. This leads to arranging the pipes //as wood:// by default and on top level as list, optionally expanding into a subtree with automatic rooting, augmented by the ability to route any output to any input (cycles being detected and flagged as error). +
+
//some information how to achieve custom drawing with ~GTKmm...//
+valuable reference documentation comes bundled with lib ~GTKmm, in the guide [["Programming with GTKmm|https://developer.gnome.org/gtkmm-tutorial/stable/index.html.en]]
+* the chapter detailing [[use of the Gtk::DrawingArea|https://developer.gnome.org/gtkmm-tutorial/stable/chapter-drawingarea.html.en]], including an introduction to [[Cairomm|https://www.cairographics.org/documentation/cairomm/reference/]]
+* the chapter about [[constructing a custom widget|https://developer.gnome.org/gtkmm-tutorial/stable/sec-custom-widgets.html.en]]
+
+Basically we have to handle the {{{signal_draw}}} events. Since we need to control the event processing, it is recommended to do this event handling by //overriding the {{{on_draw()}}} function,// not by connecting a slot directly to the signal. Two details are to be considered here: the //return value// controls if the event can be considered as fully handled. If we return {{{false}}}, enclosing (parent) widgets get also to handle this event. And, secondly, if we derive from any widget, it is a good idea to invoke the //parent implementation of {{{on_draw()}}} at the appropriate point.// This is especially relevant when our custom drawing involves the ''canvas widget'' ({{{Gtk::Layout}}}), which has the ability to place several further widgets embedded onto the canvas area. Without invoking this parent event handler, those embedded widgets won't be shown.
+
+
//This is the canvas widget of ~GTK-3//
 It allows not only custom drawing, but also to embed other widgets at defined coordinates.
@@ -2635,7 +2644,7 @@ In the most general case, there can be per-track content and nested content at t
 &rarr; 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).
 
@@ -2716,6 +2725,8 @@ In order to build a sensible plan for our timeline structure, we need to investi
 ://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
+;about GtkCustomDrawing
+:need to derive from {{{Gtk::Layout}}} and override the {{{on_draw(cairocontext)}}} function
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 20f6ac27e..b87d5b55b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -8,7 +8,19 @@ - + + + + + + + + + + + + + @@ -9269,8 +9281,24 @@ + + + + + + + + + + + + + + + - + + @@ -9291,8 +9319,29 @@ - + + + + + + + +

+ in der Implementierung, mywidget.cc +

+

+ ist eine komplette Sequenz, wie man einen CSS-StyleProvider setzt +

+

+ und auch ein Signal für Parse-Fehler anschließt +

+ + + + + + @@ -9355,6 +9404,41 @@ + + + + + + + + + + + + + + + + + + + + + + +

+ ...meaning, "this event is not yet fully processed", +

+

+ i.e. the enclosing parent widget also gets a chance to redraw itself +

+ + + + + + +