From 90cc17b7331f7c41f4682a9f6784d443bfa21554 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 30 Oct 2016 02:55:38 +0100 Subject: [PATCH] Inv(#1020): learn how to draw a simple line here we draw a red diagnoal line behind the embedded widgets. --- src/gui/panel/timeline-panel.cpp | 22 ++++++++++++++++++---- wiki/renderengine.html | 11 +++++++++-- wiki/thinkPad.ichthyo.mm | 28 ++++++++++++++++++++++++++-- 3 files changed, 53 insertions(+), 8 deletions(-) diff --git a/src/gui/panel/timeline-panel.cpp b/src/gui/panel/timeline-panel.cpp index d111efba6..588a62431 100644 --- a/src/gui/panel/timeline-panel.cpp +++ b/src/gui/panel/timeline-panel.cpp @@ -248,10 +248,15 @@ namespace panel { Canvas::enableDraw (bool yes) { shallDraw_ = yes; - if (shallDraw_) + + // force redrawing of the visible area... + auto win = get_window(); + if (win) { - ///TODO invalidate - cout << "DRRRRAW!"<invalidate_rect(rect, false); } } @@ -261,7 +266,16 @@ namespace panel { { if (shallDraw_) { - cout << "Canvas::on_draw("<set_line_width (10.0); + + // draw red diagonal line + cox->set_source_rgb(0.8, 0.0, 0.0); + cox->move_to(0, 0); + cox->line_to(w, h); + cox->stroke(); } return Gtk::Layout::on_draw(cox); } diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 747f84b9f..9787afe2e 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2398,13 +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.
+
+Typically, when starting the draw operation, we retrieve our //allocation.// This is precisely the rectangle reserved for the current widget, //insofar it is visible.// Especially this means, when a larger canvas is partially shown with the help of scrollbars, the allocation is the actually visible rectangle, not the virtual extension of the canvas.
@@ -2644,7 +2646,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).
 
@@ -2727,6 +2729,11 @@ In order to build a sensible plan for our timeline structure, we need to investi
 :* 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
+:* layering is controlled by the order of the cairo calls, plus the point when the inherited {{{Gtk::Layout::on_draw()}}} is invoked
+:** when invoked //before// our custom drawing, we draw on top of the embedded widgets
+:** when invoked //after// our custom drawing, the embedded widgets stay on top
+:* the {{{Gtk::Allocation}}} is precisely the visible screen area reserved for the widget.<br/>It is //not// the extension of the virtual canvas.
+:* ...consequently, if our drawing shall be stitched to the canvas, we need to care for translation and for clipping ourselves.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index b87d5b55b..c71602c6d 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -9414,7 +9414,8 @@ - + + @@ -9437,7 +9438,30 @@ - + + + + + + + +

+ Warning: allocation is the visible area +

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