The presentation of the track body area relies on the [[Gtk::Layout "canvas widget"|GtkLayoutWidget]], thus allowing for a mixture of custom drawing with embedded custom Gtk widgets. The actual drawing routine is activated in response to the {{{on_draw}}} signal -- and invoking the inherited handler function will initiate the standard drawing for the embedded child widgets. This partitions the additional, specific drawing activities into a pre-widget drawing phase to prepare the background and framework structure of the track area, and a post-widget drawing phase to show all kinds of overlays, markers cursors and similar UI indicators. A nested structure of {{{TrackBody}}} objects serves as organisational device to structure these custom drawing activities in accordance with the nested structure of the track fork.
!Building a nested 3D structure
@@ -3545,6 +3545,32 @@ The actual expression of these elements depends on the content, which is injecte
| | | !__Track-11__ |>|>|>|>|!__Track-12__ | |
|~|~|>| | |!__Track-121__ |!__Track-122__ | |~|
|r(1),r(1),g,''c''(2)|⤵|r(1),g,''c''(3)|r(1),g,r(1)|⤵|r(1),''c''(2) |r(1),''c''(1)|⤴|⤴|
+
+
+!!!Drawing strategy
+Once the fundamental decision towards a 3D structure is taken, there still is some room for choices regarding the actual strategy to perform the drawing primitives. However, there are also known limitations in what can be achieved by shading within an essentially flat drawing (unless we'll get some kind of holographic display technology at our disposal, somewhere in the future). The point to note is, we can not convey a fully three dimensional structure merely through shading -- rather we can only imply //local depth relations.// And since the actual structure of our nested tracks can be quite elaborate and wide spanning, we should focus on expressing such local relations, in order to support the user and help to grasp the presented structure.
+* shading can indicate a //barrier.//
+* shading can indicate a //slope// up or down.
+An immediate consequence to draw from this observation is that ~CSS3 effects are only of limited use for this purpose. They are more helpful to highlight compact and local structures, like a menu button, or some element or handle on the clips. We can (and likely will) use CSS shading for the [[track overview rulers|TrackRuler]] though. We possibly could use a slight inset box shadow within the actual track content area. However, it is rather pointless to use a box shadow to paint the nested track scope insets -- we rather need to rely on gradients and direct colour shading for that purpose.
+
+Another consequence is that we do not need to apply an overall "stacked boxes" approach -- there is not much to gain from doing so (and we would do a lot of unnecessary filling operations, most of which will actually clipped away). For that reason, we define our ''track profile'' to represent a vertical //top-down drawing sweep.// Non the less, the actual colours and shades can be defined completely through CSS rules. To achieve this, we apply some tricks
+* we define //virtual widgets,// which are only used to match against selectors and pick up the attached CSS styles
+** the virtual element {{{fork}}} represents "a timeline track"
+** and a virtual {{{frame}}} element nested therein represents "a ruler on top of a timeline track"
+* this leads to the following selectors to attach the actual styling rules
+*;track fork
+*:attach rules to the selector {{{.timeline__page > .timeline__body fork.timeline__fork}}}
+*:* the {{{border top}}} and {{{border bottom}}} rules will be used to //draw the nested inset.//
+*:* a {{{margin}}} at top will add additional space between consecutive tracks
+*:* while the {{{padding}}} will be used within the track content area -- <br/> of course only in vertical direction, since the horizontal extension is ruled by the time position of elements within the track
+*:* please note that {{{background}}} stylings apply to the //content area// and not the track space at a whole.
+*;track ruler
+*:attach rules to the selector{{{fork.timeline__fork frame.timeline__ruler}}}
+*:* again the {{{border top}}} and {{{border bottom}}} settings will delimit the ruler form the other track content
+*:* while {{{margin}}} and {{{padding}}} apply as usual outside and within the border
+*:* here the {{{box shadow}}} will be drawn with the background -- however, only an {{{inset}}} makes sense here,<br/>since a regular (outer) box shadow will be covered by consecutive drawing actions, unless it sticks within the limits of the {{{margin}}}
+
+Please note also that our drawing code operates in several ''passes''. First, a ''background'' pass is used to fill the area, then GTK is invoked recursively for any widgets on the dawing canvas, most notably the ''clips''. Then, a final ''overlay'' pass allows to paint range markers, selections and indicators on top.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index dcb92b637..a95646635 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -19392,8 +19392,8 @@
-
+
@@ -19453,8 +19453,7 @@
aber die tatsächliche Neuberechnung erfolgt erst spät, und bei Bedarf