Design: considerations regarding widget structure in the timeline

wiki/renderengine.html

@@ -2324,9 +2324,9 @@ Now, when invoking an operation on some public interface, the code in the lower
 <pre>A specially configured LumieraPlugin, which actually contains or loads the complete code of the (GTK)GUI, and additionally is linked dynamically against the application core lib. During the [[UI startup process|GuiStart]], loading of this Plugin is triggered from {{{main()}}}. Actually this causes spawning of the GTK event thread and execution of the GTK main loop.
 </pre>
 </div>
-<div title="GuiTimelineView" creator="Ichthyostega" modifier="Ichthyostega" created="201410160100" modified="201410160235" tags="GuiPattern design decision draft" changecount="4">
+<div title="GuiTimelineView" creator="Ichthyostega" modifier="Ichthyostega" created="201410160100" modified="201410242358" tags="GuiPattern design decision draft" changecount="7">
 <pre>Within the Lumieara GUI, the [[Timeline]] structure(s) from the HighLevelModel are arranged and presented according to the following principles and conventions.
-Several timeline views may be present at the same time -- and there is not necessarily a relation between them, since »a Timeline« is the top-level concept within the [[Session]]. Obviously, there can also be several //views// based on the same »Timeline« model element, and in this latter case, these view behave according to a linked common state. An entity »Timeline« as represented through the GUI, emerges from the combination of several model elements
+Several timeline views may be present at the same time -- and there is not necessarily a relation between them, since »a Timeline« is the top-level concept within the [[Session]]. Obviously, there can also be several //views// based on the same »Timeline« model element, and in this latter case, these //coupled views// behave according to a linked common state. An entity »Timeline« as represented through the GUI, emerges from the combination of several model elements
 * a root level [[Binding|BindingMO]] acts as framework
 * this binding in turn ties a [[Sequence]]
 * and the sequence provides a [[tree of Tracks|Track]]
@@ -2349,7 +2349,43 @@ This collapsed, expanded and possibly nested workspace structure is always exact
 
 !!!nesting
 By principle, this workspace structure is //not a list of &quot;Tracks&quot;// -- it is a system of ''nested scopes''. The nesting emerges on demand.
-In the most general case, there can be pr-track content and nested content at the same point in time. The GUI is able to represent this state. But, due to the semantics of Lumiera's HighLevelModel,  top-level content and nested content are siblings //within the same scope.// Thus, at a suitable point {{red{to be defined}}}, an equivalence transformation is applied to the GUI model, by prepending a new sibling track and moving top-level content there.
+In the most general case, there can be per-track content and nested content at the same point in time. The GUI is able to represent this state. But, due to the semantics of Lumiera's HighLevelModel,  top-level content and nested content are siblings //within the same scope.// Thus, at a suitable point {{red{to be defined}}}, an equivalence transformation is applied to the GUI model, by prepending a new sibling track and moving top-level content there.
+
+&amp;rarr; important question: how to [[organise the widgets|GuiTimelineWidgetStructure]]
+</pre>
+</div>
+<div title="GuiTimelineWidgetStructure" creator="Ichthyostega" modifier="Ichthyostega" created="201410250002" modified="201410250103" tags="GuiPattern discuss decision impl" changecount="22">
+<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).
+
+!two fundamental models
+It is clear that we need to write a customised widget (just because there are way to much specifics as to spell them out flat on top level). Two distinct approaches are conceivable
+;custom arrangement
+:define or derive our own widget class to arrange existing widgets in a customised way
+;custom drawing
+:get the allocated screen area for our widget and perform all drawing and event updating explicitly in our own code
+
+!!!perils of custom drawing
+While the second approach intuitively seems to be adequate (and in fact, Cinelerra, Ardour and our own GUI choose this approach), we should note several problematic aspects
+* once we &quot;take over&quot;, we are entirely responsible for &quot;our area&quot; and GTK steps out of our way
+* we have to replicate and code up any behaviour we want and know from the standard GUI
+* chances are that we are handling some aspects different than the default, without even noticing there is a default
+* chances are that we are lacking the manpower to cope with all interdependencies of concrete presentation situation, custom styling and event state
+Our custom made UI elements impend to turn into a tremendous time sink (For reference, Paul Davis reported for Ardour 2.x that he spent 80% of the developer time not with audio processing, but rather with bashing the UI into shape), while delivering a crappy, home-brew and misaligned user experience and generally stand out as an alien element not playing well with the rest of the desktop.
+{{red{Well}}} //at least we are aware of the danger.//
+
+!!!is custom drawing necessary?
+There are some issues though, which more or less force us into custom drawing
+* for our task, we're suffering a horrible lack of screen real estate. This forces us into conceiving elaborate controls way beyond the capabilities of existing standard widgets
+* and for the feedback, we also need to tap into very precise event handling, which is hard to achieve with the huge amount of variability found with standard widgets
+* our display has to comply to a temporal metric, which is incompatible with the leeway present in standard widgets for the purpose of styling and skinning the UI
+* the sheer amount of individual elements we need to get to screen is way beyond anything in a conventional GUI -- the UI toolkit set can not be expected to handle such load smoothly
+
+!Remedy: A Canvas Control
+All of the above is a serious concern. There is no easy way out, since, for the beginning, we need to get hands on with the display -- to get any tangible elements to work against. Yet we might come up with a plan of attack and we might align even the preliminary steps in a way to switch to a more durable solution once we get a chance to do so. The desired solution is to build our own ''Canvas Control'' to be as much in line with existing widgets and GTK conventions as possible. This is, instead of just jumping into our own drawing code heads first.
+* to the outside, make this control as much a well behaved ~GTK-3 widget or container as possible
+* learn about theming and styling engines and integrate with them to retrieve the platform look-and-feel
+* consider the ability to ''integrate regular GTK widgets'' onto our Custom Canvas. Try to figure out the regular event handling and try to forward to the embedded widgets. On success, this would allow to pass back into existing implementation and use standard code for standard stuff, even if we need to do the frame decoration and some event handling ourselves.
 </pre>
 </div>
 <div title="HighLevelModel" modifier="Ichthyostega" created="200808152311" modified="201410160108" tags="Model spec design discuss img" changecount="1">