benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Inv(#1020): learn how to draw a simple line

Browse source 
here we draw a red diagnoal line behind the embedded widgets.
This commit is contained in:
Fischlurch 2016-10-30 02:55:38 +01:00
parent 1255a4fc04
commit 90cc17b733
3 changed files with 53 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
src/gui/panel/timeline-panel.cpp
View file

@ -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!"<<endl;
int w = get_allocation().get_width();
int h = get_allocation().get_height();
Gdk::Rectangle rect{0, 0, w, h};
win->invalidate_rect(rect, false);
}
}
@ -261,7 +266,16 @@ namespace panel {
{
if (shallDraw_)
{
cout << "Canvas::on_draw("<<cox<<");"<<endl;
int w = get_allocation().get_width();
int h = get_allocation().get_height();
cox->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);
}

11
wiki/renderengine.html
View file

@ -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).
</pre>
</div>
<div title="GtkCustomDrawing" creator="Ichthyostega" modifier="Ichthyostega" created="201610300111" modified="201610300113" tags="spec GuiPattern" changecount="6">
<div title="GtkCustomDrawing" creator="Ichthyostega" modifier="Ichthyostega" created="201610300111" modified="201610300154" tags="spec GuiPattern" changecount="7">
<pre>//some information how to achieve custom drawing with ~GTKmm...//
valuable reference documentation comes bundled with lib ~GTKmm, in the guide [[&quot;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.
</pre>
</div>
<div title="GtkLayoutWidget" creator="Ichthyostega" modifier="Ichthyostega" created="201610141819" modified="201610141820" tags="GuiPattern impl" changecount="3">
@ -2644,7 +2646,7 @@ In the most general case, there can be per-track content and nested content at t
&amp;rarr; important question: how to [[organise the widgets|GuiTimelineWidgetStructure]]
</pre>
</div>
<div title="GuiTimelineWidgetStructure" creator="Ichthyostega" modifier="Ichthyostega" created="201410250002" modified="201610300058" tags="GuiPattern discuss decision impl" changecount="50">
<div title="GuiTimelineWidgetStructure" creator="Ichthyostega" modifier="Ichthyostega" created="201410250002" modified="201610300152" tags="GuiPattern discuss decision impl" changecount="51">
<pre>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.&lt;br/&gt;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.
</pre>
</div>
<div title="HighLevelModel" modifier="Ichthyostega" created="200808152311" modified="201505310109" tags="Model spec design discuss img" changecount="2">

28
wiki/thinkPad.ichthyo.mm
View file

@ -9414,7 +9414,8 @@
</node>
<node CREATED="1477789514451" ID="ID_84890591" LINK="https://www.cairographics.org/documentation/cairomm/reference/" MODIFIED="1477789523593" TEXT="Cairomm API-doc"/>
</node>
<node CREATED="1477784938038" ID="ID_93104177" MODIFIED="1477784941482" TEXT="how-to...">
<node CREATED="1477784938038" ID="ID_93104177" MODIFIED="1477791977201" TEXT="how-to...">
<icon BUILTIN="button_ok"/>
<node CREATED="1477788718965" ID="ID_1354942176" MODIFIED="1477788722040" TEXT="derived class"/>
<node CREATED="1477788722228" ID="ID_720985572" MODIFIED="1477788730239" TEXT="override on_draw()"/>
<node CREATED="1477788731163" ID="ID_421749777" MODIFIED="1477788740646" TEXT="invoke inherited on_draw()">
@ -9437,7 +9438,30 @@
</richcontent>
</node>
</node>
<node CREATED="1477784943797" ID="ID_298493039" MODIFIED="1477784946617" TEXT="layering"/>
<node CREATED="1477791881630" ID="ID_1823256674" MODIFIED="1477791884001" TEXT="coordinates">
<node CREATED="1477791885614" ID="ID_380369648" MODIFIED="1477791916343">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
<font color="#bd0053">Warning</font>: allocation is the <i>visible</i>&#160;area
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1477791921953" ID="ID_555455740" MODIFIED="1477791952896" TEXT="...not the extension of the canvas!"/>
</node>
<node CREATED="1477784943797" ID="ID_298493039" MODIFIED="1477791972306" TEXT="layering">
<icon BUILTIN="button_ok"/>
<node CREATED="1477791842091" ID="ID_671463871" MODIFIED="1477791848942" TEXT="depends on order of parent call"/>
<node CREATED="1477791849578" ID="ID_96793101" MODIFIED="1477791858929" TEXT="and on order of cairo draw operations">
<icon BUILTIN="ksmiletris"/>
</node>
</node>
<node CREATED="1477784949533" ID="ID_1496795315" MODIFIED="1477784952776" TEXT="custom styling"/>
</node>
<node CREATED="1477595418670" ID="ID_770195423" MODIFIED="1477596119220" TEXT="# place a huge number of widgets, to scrutinise scrolling and performance">