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

Timeline: document use of custom CSS rules

Browse source 
The drawing code extracts style information from some "virtual"
widgets, which serve as logical placeholder for the actual nested
structure of tracks.

For sake of demonstration, I used rather obvious colours and
also all kinds of margin and padding; a screenshot was added
with annotations to indicate where some specific style settings
are utilised from the drawing code
This commit is contained in:
Fischlurch 2023-03-16 01:16:37 +01:00
parent 8fec337f60
commit 8d9846837d
9 changed files with 617 additions and 42 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

393
doc/devel/draw/TimelineCSS.svg Normal file
View file

File diff suppressed because one or more lines are too long
Side by side

After

Width:  |  Height:  |  Size: 69 KiB

1
doc/devel/images/TimelineCSS.png Symbolic link
View file

@ -0,0 +1 @@
../draw/rendered/TimelineCSS.png

4
doc/technical/code/c++11.txt
View file

@ -189,7 +189,7 @@ construction objects, when _it is important to avoid spurious copying,_ it is be
helper function do the actual ctor invocation.
WARNING: One insidious point to note is the rule that _explicitly defining a destructor_ will automatically
_suppress an otherwise automatically defined, implicit move constructor._ Move ctors really behave
_suppress an otherwise automatically defined, implicit move constructor._ In this respect, move constructors behave
different than implicitly defined copy constructors; this was an often criticised, unfortunate
design decision for C++. So the common advice is to observe the »**rule of five**«: ``whenever you
define one of them, then define all of them''.footnote:[And it is sufficient to use `=default`
@ -315,7 +315,7 @@ impose some challenging effort to retrofit existing structures.
to what we've done for C++11 to use our iterators and pipelines with the new standard ``for each'' loops.
- *Modules* do not solve any real problems for the code base in its current shape. A migration to modules is
mostly a rather mechanical task, while requiring a fairly good understanding of the ``dark corners'' in the
a rather mechanical task largely, while requiring a fairly good understanding of the ``dark corners'' in the
code base, like e.g. the size and build time for test code. Such a transition will also raise again the topic
of the buildsystem. Unfortunately, what we've built on top of Scons with a little bit of python scripting is
much cleaner and high-level than most ``mainstream'' usage of other common build systems out there.footnote:[

2
doc/technical/code/codingGuidelines.txt
View file

@ -104,7 +104,7 @@ General Code Arrangement and Layout
- the includes for our own dependencies shall be given relative to source-root (or test root). Don't use
relative includes for headers located in the same directory, or -- worse still -- in the parent directory.
- sometimes, the actual translation units will combine several facilities for technical reasons.footnote:[to
elaborate, there can be ``headers'', which are in fact only be intended for inclusion at one or two distinct
elaborate, there can be ``headers'', which are in fact only intended for inclusion at one or two distinct
places. This should be mentioned in the file-level comment, but generally is an acceptable practice,
and better then lumping everything into a 1000 lines header. As a guideline, if you expect a rather
technical concern not to be of much interest for most readers of a header, then better extract it into

16
doc/technical/library/DiffFramework.txt
View file

@ -306,9 +306,9 @@ mutation. Some typical ``degenerated'' patterns of spelling out a diff are as fo
position or the identity of the element.
representation of objects
Representation of objects
~~~~~~~~~~~~~~~~~~~~~~~~~
While we are talking about _structured data,_ in fact the entities we are about to handle are *objects*, understood in
While we are talking about _structured data,_ in fact the entities we are about to handle are *objects*, conceived in
the standard flavour of object orientation, where an object is the instance of a type and offers a contract. Incidentally,
this is not the original, ``pure'' meaning of object orientation, but the one that became prolific to bring our daily
practice closer to the inherent structuring of modern human organisation. And in dealing with this kind of object, we
@ -323,23 +323,23 @@ and if not, we'll get what we deserve.footnote:[This gives rise to a tricky disc
and the costs incurred by that happening. We should not treat this topic in isolation; we should recall that
loose coupling was chosen to avoid far more serious problems caused by tight coupling, and especially the
deteriorating and poisoning effect on architecture and the further dire consequences of a global fixed common
data model -- which become prdominant when used in a large, not homogeneous system.
data model -- which prevail when used in large, not heterogenous systems.
And _when a system indeed is not homogeneous,_ we better try to make each part open-closed, open for change
but closed against extension. This is especially true in the case of the UI.]
object representation protocol
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A diff is created to tell some partner about our data, and the »protocol to describe an object« is as follows
A diff is created to tell some partner about our data, and the »protocol to describe an object« is defined as follows...
- the ID is the object's identity and is once given, right at start, and never changed
- we spell out any metadata (esp. a type information) first, followed by all attributes,
- the ID is the object's identity and is given once, right at start, and never changed
- we spell out any metadata first (esp. type information), followed by all attributes,
and then followed by contents of the object's scope (children).
- attributes are to be given in a way not in contradiction to the more stringent semantics
- attributes are to be given such as not to counter the more stringent semantics
of an object field or property
* never attempt to re-order or delete such attributes, since their presence is fixed in the class definition
* when a field is mandatory _by its nature,_ it shall be required in construction, and the corresponding data
* when a field is mandatory _by its nature,_ it shall be required at construction, and the corresponding data
is to be given with the `ins` verb causing the constructor call
* on the other hand, the data for an optional field, when present, shall be spelled out by `ins` verb
after construction, with the first _population diff._

59
doc/technical/stage/style/Timeline.txt
View file

@ -50,19 +50,19 @@ This leads to the following structure of selectors to attach the actual styling
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._
- 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 --
+
of course only in vertical direction, since the horizontal extension is ruled by the time position of elements within the track
- please also note that `background` stylings apply to the _content area_ and not the track space at a whole.
- especially a `box shadow` will be drawn when filling the background of the content area -- however,
- especially a `box-shadow` will be drawn when filling the background of the content area -- however,
only an `inset` makes sense here, since a regular (outer) box shadow will be obscured and covered up
by consecutive drawing actions...
track ruler::
use a **`frame`** element and 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
- again the `border` `top` and `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 and aligned with the frame --
and again, only an `inset` really makes sense, while a regular (outer) box shadow must be
@ -85,18 +85,53 @@ header::
fork head::
Located within the PatchbayWidget resides a nested structure of fork head controls
- each such TrackHeadWidget is derived from Gtk::Grid and marked with class `.fork__head`
- the first row in the grid holds a Track Header label and menu,an ElementBoxWidget with class `.elementbox`
- the second row corresponds to the _content area_ of the track itself,
and hold the controls for this track's scope, i.e. the track _together with all nested sub-tracks._
- in the second cell in this row resides the HeadControlArea with class `.fork__control`
- the first row in the grid holds a Track Header label and menu, an ElementBoxWidget with class `.elementbox`
- the second row corresponds to the _content area_ of the track itself
- in the second cell in this row resides the HeadControlArea with class `.fork__control` -- which
houses the controls for this track's scope, i.e. the track _together with all nested sub-tracks._
- next comes a padding row to help synchronising track head and track body display
- Additional sub-Tracks are added as additional lines to the grid, and each such line
will hold a nested TrackHeadWidget in the second cell; this also implies that this
nested sub-Track head can again hold deeper nested sub-Tracks....
- The first column to the left side, starting from the second row will be increased accordingly to indicate
nested sub-Track head can again hold deeper nested sub-Tracks recursively....
- The first column to the left side, starting from the second row, will be increased accordingly to indicate
the nested fork structure, rendered as a nested set of »stave brackets« with class `.fork__bracket`
[red]##TODO 10/2022:##
- [red]##give an example what our custom drawing code actually extracts and uses##
- [red]##also document a resulting selector for an actual Clip element in a concrete timeline##
Demonstration of CSS for custom drawing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The example below demonstrates how CSS rules are picked up and used for custom drawing of the fork structure
onto the Timeline body canvas. For sake of demonstration, the drawing code was manipulated slightly, by shifting
borders to reveal the box shadow effect, and to show canvas content beyond the timeline end.
Lumiera used the »light theme complement« stylesheet for this demonstration -- thus most of the styles are derived
from the custom desktop theme. A few additional class definitions were added for styling of the timeline body display,
using rather distinct colours and excessive padding and margins to emphasise their effect on the drawing routine
[source,css]
--------------------------------------------------------------------------
.timeline__page > .timeline__body fork.timeline__fork {
margin: 2ex;
padding: 10px;
border-style: inset;
border-color: IndianRed;
background-color: Lime;
box-shadow: inset 2px 2px 5px 1px DeepSkyBlue,
5px 5px 2px 1px ForestGreen;
}
fork.timeline__fork frame.timeline__ruler {
margin: 1ex;
padding: 5px;
border: 3px outset DarkGoldenRod;
background-color: SandyBrown;
box-shadow: inset 2px 2px 5px 1px RosyBrown,
5px 3px 6px 4px Sienna;
}
--------------------------------------------------------------------------
image:{imgd}/TimelineCSS.png["Demonstration of CSS for custom drawing"]
[red]##TODO 3/2023:##
- [red]##should also document the selector for an actual Clip element in a concrete timeline##

BIN
wiki/draw/TimelineCSS.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 99 KiB

74
wiki/renderengine.html
View file

@ -3629,7 +3629,7 @@ In accordance with the Lumiera application architecture in general, the UI is no
<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="GuiTimelineDraw" creator="Ichthyostega" modifier="Ichthyostega" created="201904052156" modified="201912061632" tags="GuiPattern spec impl img draft" changecount="107">
<div title="GuiTimelineDraw" creator="Ichthyostega" modifier="Ichthyostega" created="201904052156" modified="202303120009" tags="GuiPattern spec impl img draft" changecount="112">
<pre>The presentation of the track body area relies on the [[Gtk::Layout &quot;canvas widget&quot;|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
@ -3658,23 +3658,23 @@ Once the fundamental decision towards a 3D structure is taken, there still is so
* 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 &quot;stacked boxes&quot; 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 be 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
Another consequence is that we do not need to apply an overall &quot;stacked boxes&quot; 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 be 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|GuiTimelineStyle]]. 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 &quot;a timeline track&quot;
** and a virtual {{{frame}}} element nested therein represents &quot;a ruler on top of a timeline track&quot;
* this leads to the following selectors to attach the actual styling rules
* this leads to the following selectors to attach the &amp;rarr; [[actual styling rules|GuiTimelineStyle]]
*;track fork
*:attach rules to the selector {{{.timeline__page &gt; .timeline__body fork.timeline__fork}}}
*:* the {{{border top}}} and {{{border bottom}}} rules will be used to //draw the nested inset.//
*:* 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 -- &lt;br/&gt; 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.
*:* especially a {{{box shadow}}} will be drawn when filling the background of the content area -- however, only an {{{inset}}} makes sense here,&lt;br/&gt;since a regular (outer) box shadow will be covered by consecutive drawing actions...
*:* especially a {{{box-shadow}}} will be drawn when filling the background of the content area -- however, only an {{{inset}}} makes sense here,&lt;br/&gt;since a regular (outer) box shadow will be covered by consecutive drawing actions...
*;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
*:* again the {{{border}}} ({{{top}}} and {{{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 and aligned with the frame -- and again, only an {{{inset}}} really makes sense,&lt;br/&gt;while a regular (outer) box shadow must be small enough to stick within the limits of the {{{margin}}}
*:* here the {{{box-shadow}}} will be drawn with the background and aligned with the frame -- and again, only an {{{inset}}} really makes sense,&lt;br/&gt;while a regular (outer) box shadow must be small enough to stick within the limits of the {{{margin}}}
*;slopes
*:we use several classes to define the effect of consecutive nested frames forming a common slope; however,
*:we perform this combination effect only with a limit of 5 steps depth. Only closing (upward) slopes can be combined.
@ -3701,7 +3701,57 @@ Now, since we build our UI on the notion of mapping session contents via a messa
In any case, this is an advanced topic, and nowhere near trivial. It seems reasonable to reject opening duplicate timeline presentations as a first step, and then address this topic way later, when we've gained sufficient knowledge regarding all the subtleties of timeline presentation and editing.</pre>
</div>
<div title="GuiTimelineView" creator="Ichthyostega" modifier="Ichthyostega" created="201410160100" modified="202303042311" tags="GuiPattern design decision draft img" changecount="68">
<div title="GuiTimelineStyle" creator="Ichthyostega" modifier="Ichthyostega" created="202303112351" modified="202303162330" tags="GuiPattern spec impl img draft" changecount="14">
<pre>In parts, the Lumiera Timeline UI will be implemented by custom drawing onto a //Canvas Control,// using libCairo for the actual drawing operations. Beyond the challenge of coordinating an elaborated and nested layout, a special twist arises from the ability for custom styling, present in most contemporary desktop environments -- without special precautions, our custom drawing runs danger of creating a visual style separate and in contradiction to the common style set by the chosen desktop theme. This challenge can be resolved, at least in part, by tapping into the existing CSS definitions, to retrieve the necessary settings and adapt them to our special needs.
To this end, a hierarchy of virtual placeholder widgets is used by the »~StyleManager« in {{{stage::workspace::UiStyle::prepareStyleContext()}}} -- these will represent the structures actually created by custom drawing, and allow to retrieve any CSS definitions applicable at that point in the style class hierarchy.
As outlined in the [[explanation of the actual drawing code|GuiTimelineDraw]], this virtual style hierarchy is comprised of several selectors...
* the virtual element {{{fork}}} represents &quot;a timeline track&quot;
** the selector {{{.timeline__page &gt; .timeline__body fork.timeline__fork}}} will pick up definitions
*** to define the //appearance of the nested inset// based on {{{border}}} settings ({{{top}}} and {{{bottom}}})
*** a {{{margin}}} at top will add additional space between consecutive tracks
*** while the {{{padding}}} in vertical direction will be used within the track content area
*** please note that {{{background}}} stylings apply to the //content area// and not the track space at a whole.
*** especially a {{{box-shadow}}} will be drawn when filling the background of the content area -- however, only an {{{inset}}} makes sense here,&lt;br/&gt;since a regular (outer) box shadow will be covered by consecutive drawing actions...
* a virtual {{{frame}}} element nested within the {{{fork}}} represents &quot;a ruler on top of a timeline track&quot;
** here the selector{{{fork.timeline__fork frame.timeline__ruler}}} will pick up appropriate definitions
*** 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 and aligned with the frame -- and again, only an {{{inset}}} really makes sense,&lt;br/&gt;while a regular (outer) {{{box-shadow}}} must be small enough to stick within the limits of the {{{margin}}}
* Slopes connecting nested sub-Tracks will be governed by styles...
** we use class {{{.track-slope--deep1}}} for a simple slope (inset by one nested level)
** class {{{.track-slope--deep2}}} for two consecutive nested steps combined.
** likewise class {{{.track-slope--deep3}}} for three and class {{{.track-slope--deep4}}} for four combined slopes
** finally, class {{{.track-slope--verydeep}}} is used for five and more combined upward (closing) slopes
!Demonstration of CSS for custom drawing
The example below demonstrates how CSS rules are picked up and used for custom drawing of the fork structure on the Timeline body canvas.
For sake of demonstration, the drawing code was slightly manipulated, so to shift borders and show canvas content beyond the timeline end.
Lumiera used the »light theme complement« stylesheet -- thus most of the styles are drawn from the desktop theme.
A few additional class definitions were added for styling of the timeline body display
{{{
.timeline__page &gt; .timeline__body fork.timeline__fork {
margin: 2ex;
padding: 10px;
border-style: inset;
border-color: IndianRed;
background-color: Lime;
box-shadow: inset 2px 2px 5px 1px DeepSkyBlue,
5px 5px 2px 1px ForestGreen;
}
fork.timeline__fork frame.timeline__ruler {
margin: 1ex;
padding: 5px;
border: 3px outset DarkGoldenRod;
background-color: SandyBrown;
box-shadow: inset 2px 2px 5px 1px RosyBrown,
5px 3px 6px 4px Sienna;
}
}}}
[&gt;img[Demonstration of CSS for custom drawing|draw/TimelineCSS.png]]</pre>
</div>
<div title="GuiTimelineView" creator="Ichthyostega" modifier="Ichthyostega" created="201410160100" modified="202303112339" tags="GuiPattern design decision draft img" changecount="70">
<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 //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
@ -3742,7 +3792,11 @@ The dockable ''timeline pannel'' holds onto the existing {{{TimelineWidget}}} in
In case the UI starts with no session present in the core, an //empty timeline placeholder// will be displayed, which provides UI for creating a new session...
!!!The Canvas
At least the track body area of the timeline display needs to be implemented in parts by //custom drawing// onto a [[»Canvas widget«|GtkLayoutWidget]] -- meaning that we have both to coordinate explicit graphic operations using the »Cairo« library, and child widgets attached at explicit positions on top of this canvas. These nested widgets in turn need to know about the calibration of the canvas in terms of time and pixels, to be able to adjust their display to fit into the established metric. As the first implementation attempt for the timeline highlighted, at this point there is a lurking danger to slide into the usage of one central „God class“ -- in this case a //Layout Manager// -- which has to actuate and coordinate any related interplay by „pulling the strings“ like a puppeteer. To forego that threat, we introduce yet another abstraction: a [[»Canvas Interface«|GuiCanvasInterface]] to support attachment of widgets and handle the translation of logical (time based) coordinates into pixel values.
At least the track body area of the timeline display needs to be implemented in parts by //custom drawing// onto a [[»Canvas widget«|GtkLayoutWidget]] -- meaning that we have both to coordinate explicit graphic operations using the »Cairo« library, and child widgets attached at explicit positions on top of this canvas. These nested widgets in turn need to know about the calibration of the canvas in terms of time and pixels, to be able to adjust their display to fit into the established metric. As the first implementation attempt for the timeline highlighted, at this point there is a lurking danger to slide into the usage of one central „God class“ -- in this case a //Layout Manager// -- which has to actuate and coordinate any related interplay by „pulling the strings“ like a puppeteer. To forego that contraption, we introduce yet another abstraction: a [[»Canvas Interface«|GuiCanvasInterface]] to support attachment of widgets and handle the translation of logical (time based) coordinates into pixel values.
Another difficulty arises from the ability for custom styling, present in most contemporary desktop environments -- which is typically implemented within the UI toolkit, thereby more or less relying on a fixed set of standard widgets known in advance to the designer. Once we start implementing the visual representation based on custom drawing code, we are bound to define colours and other drawing properties, and while doing so, we are in danger of creating our own visual style separate and in contradiction to the common style set by the chosen desktop theme. This challenge can be resolved, at least in part, by tapping into the existing CSS definitions, to retrieve the necessary settings and adapt them to our special needs. A way to accomplish this, is to build a virtual hierarchy of placeholder widgets -- these will represent the structures actually created by custom drawing, while retrieving any CSS definitions applicable at that point in the style class hierarchy.
&amp;rarr; see details of [[styling the Timeline|GuiTimelineStyle]]
!!!Placements
As indicated in the drawing above, pretty much every UI element exposes a button to //edit its placement.// &amp;rarr; GuiPlacementDisplay
@ -9452,7 +9506,7 @@ The actual presentation of ruler elements is a fusion of parametrisation, track
** the ruler of an //expanded fork// (a track with nested child tracks) will typically give a summary of effective content, but can also be hidden, or feature other content
** the ruler of an //expanded leaf track// (no child tracks) will typically be hidden, but can likewise be configured to show specific data</pre>
</div>
<div title="TrackStaveBracket" creator="Ichthyostega" modifier="Ichthyostega" created="202303050037" modified="202303050303" tags="def GuiPattern img" changecount="39">
<div title="TrackStaveBracket" creator="Ichthyostega" modifier="Ichthyostega" created="202303050037" modified="202303060035" tags="def GuiPattern img" changecount="41">
<pre>//Graphical representation of the nested Track scopes as part of the TrackHead display.//
The design (and the name) of this graphical display is inspired by musical notation, where it is customary to indicate with a bracket the grouping of stems (or staves) forming an ensemble, while a brace typically groups the staves to be played on a single instrument, e.g. a grand piano or organ.

110
wiki/thinkPad.ichthyo.mm
View file

@ -6160,6 +6160,49 @@
<node CREATED="1537661322914" ID="ID_165076190" MODIFIED="1557498707219" TEXT="per synthetisiertem Widget-Path"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1678573145778" ID="ID_529832770" MODIFIED="1678576114059">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
<font size="5">Style-Scheme</font>&#160;for Lumiera
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#8b1d60" DESTINATION="ID_281557130" ENDARROW="Default" ENDINCLINATION="-1401;-108;" ID="Arrow_ID_1840161927" STARTARROW="None" STARTINCLINATION="-625;67;"/>
<icon BUILTIN="yes"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1678573175156" ID="ID_1210386404" MODIFIED="1678573180188" TEXT="entwickeln...">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1538588393995" ID="ID_1149076483" MODIFIED="1678573209829">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
#1168 : find a way to manage style of
</p>
<p>
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;custom extended UI elements
</p>
</body>
</html></richcontent>
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1678575013546" HGAP="59" ID="ID_1275966904" MODIFIED="1678575229481" TEXT="L&#xf6;sungsansatz per Prototyp best&#xe4;tigt" VSHIFT="21">
<arrowlink COLOR="#40a5bc" DESTINATION="ID_1949200690" ENDARROW="Default" ENDINCLINATION="-2003;-104;" ID="Arrow_ID_398104912" STARTARROW="None" STARTINCLINATION="2327;166;"/>
<icon BUILTIN="button_ok"/>
</node>
</node>
</node>
<node CREATED="1678576263610" ID="ID_1861505787" MODIFIED="1678576267709" TEXT="Spezialit&#xe4;ten">
<node COLOR="#435e98" CREATED="1678576309372" ID="ID_650016552" MODIFIED="1678576514278" TEXT="CSS-Styling der Timeline">
<arrowlink COLOR="#5f7783" DESTINATION="ID_1232986902" ENDARROW="Default" ENDINCLINATION="2218;-176;" ID="Arrow_ID_691307229" STARTARROW="None" STARTINCLINATION="7697;843;"/>
<icon BUILTIN="info"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1561898940013" ID="ID_1812249534" MODIFIED="1561898964578" TEXT="Aufgabe: globaler Layout-Manager">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1561898713460" ID="ID_44229333" MODIFIED="1561899095357" TEXT="Aufgabe: Theming/Styling unserer speziellen UI-Elemente">
@ -6171,9 +6214,6 @@
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1538588393995" ID="ID_1149076483" MODIFIED="1557498707219" TEXT="#1168 : find a way to manage style of custom extended UI elements">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1538695838262" ID="ID_407627538" MODIFIED="1557498707219" TEXT="lumiera-(light|dark)-theme-complement.css">
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
@ -31143,7 +31183,7 @@
<icon BUILTIN="flag-yellow"/>
<node CREATED="1672843594185" ID="ID_1806332659" MODIFIED="1672843600804" TEXT="Ausdehnung des Canvas">
<node CREATED="1672843603784" ID="ID_547988829" MODIFIED="1672843680818" TEXT="initial festlegen">
<arrowlink COLOR="#4b3d60" DESTINATION="ID_1283622298" ENDARROW="Default" ENDINCLINATION="-940;-885;" ID="Arrow_ID_425073157" STARTARROW="None" STARTINCLINATION="-693;122;"/>
<arrowlink COLOR="#4b3d60" DESTINATION="ID_1283622298" ENDARROW="Default" ENDINCLINATION="-940;-885;" ID="Arrow_ID_425073157" STARTARROW="None" STARTINCLINATION="-915;160;"/>
</node>
<node CREATED="1672843689370" ID="ID_1279756396" MODIFIED="1672843707230" TEXT="reale Ausdehnung vom ScrolledWindow contentArea_">
<node COLOR="#435e98" CREATED="1672843720006" ID="ID_1969670799" MODIFIED="1672843870753" TEXT="siehe: Size-Allokation auf GTK Widget">
@ -31245,9 +31285,21 @@
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1678841423804" ID="ID_81531339" MODIFIED="1678841644379" TEXT="Initiale Festlegung sicherstellen">
<node COLOR="#435e98" CREATED="1678841423804" ID="ID_81531339" MODIFIED="1678916678040" TEXT="&#x27f9; f&#xfc;hrt sofort zur Kalibrierung des ZoomWindow">
<arrowlink COLOR="#748598" DESTINATION="ID_833023922" ENDARROW="Default" ENDINCLINATION="-1609;-94;" ID="Arrow_ID_1971623817" STARTARROW="None" STARTINCLINATION="-140;338;"/>
<icon BUILTIN="flag-pink"/>
</node>
<node COLOR="#435e98" CREATED="1678916699994" ID="ID_868064127" MODIFIED="1678916785049" TEXT="(derzeit bleibt die Timeline auf dem Default von 23sec)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...es kommt halt nix Spezifisches aus dem Model, aber es g&#228;be auch bisher gar keine entsprechenden Diff-Bindings und Model-Properties im GUI
</p>
</body>
</html></richcontent>
<font NAME="SansSerif" SIZE="10"/>
</node>
</node>
</node>
@ -31903,7 +31955,7 @@
</node>
</node>
<node COLOR="#435e98" CREATED="1672798667029" FOLDED="true" ID="ID_1699842831" MODIFIED="1674603499873" TEXT="Integration ZoomWindow: funktioniert nicht (mehr)">
<linktarget COLOR="#ac3f80" DESTINATION="ID_1699842831" ENDARROW="Default" ENDINCLINATION="-1384;79;" ID="Arrow_ID_927325344" SOURCE="ID_133007183" STARTARROW="None" STARTINCLINATION="-1848;-74;"/>
<linktarget COLOR="#503fac" DESTINATION="ID_1699842831" ENDARROW="Default" ENDINCLINATION="-1384;79;" ID="Arrow_ID_927325344" SOURCE="ID_133007183" STARTARROW="None" STARTINCLINATION="-1848;-74;"/>
<icon BUILTIN="broken-line"/>
<node CREATED="1672798696337" ID="ID_1553490887" MODIFIED="1672798742711" TEXT="greife jetzt ScrolledWindow::get_allocated_width() ab">
<node CREATED="1672845045702" ID="ID_400583877" MODIFIED="1672845097544" TEXT="das w&#xe4;re grunds&#xe4;tzlich korrekt">
@ -32454,7 +32506,7 @@
<node CREATED="1542309666407" ID="ID_1721729181" MODIFIED="1557498707230" TEXT="initial....">
<node CREATED="1542309671333" ID="ID_1283622298" MODIFIED="1557498707230" TEXT="Gr&#xf6;&#xdf;e des leeren Canvas">
<arrowlink COLOR="#60749f" DESTINATION="ID_400560063" ENDARROW="Default" ENDINCLINATION="-46;0;" ID="Arrow_ID_449772156" STARTARROW="None" STARTINCLINATION="-13;18;"/>
<linktarget COLOR="#4b3d60" DESTINATION="ID_1283622298" ENDARROW="Default" ENDINCLINATION="-940;-885;" ID="Arrow_ID_425073157" SOURCE="ID_547988829" STARTARROW="None" STARTINCLINATION="-693;122;"/>
<linktarget COLOR="#4b3d60" DESTINATION="ID_1283622298" ENDARROW="Default" ENDINCLINATION="-940;-885;" ID="Arrow_ID_425073157" SOURCE="ID_547988829" STARTARROW="None" STARTINCLINATION="-915;160;"/>
<node CREATED="1542309689328" ID="ID_679418178" MODIFIED="1672842637926" TEXT="verwende size-Allocation des ScrolledWindow">
<richcontent TYPE="NOTE"><html>
<head>
@ -32469,6 +32521,7 @@
<arrowlink COLOR="#795b80" DESTINATION="ID_548414744" ENDARROW="Default" ENDINCLINATION="-897;636;" ID="Arrow_ID_1661740759" STARTARROW="Default" STARTINCLINATION="-286;-17;"/>
<icon BUILTIN="idea"/>
</node>
<node CREATED="1678924505204" ID="ID_25210334" MODIFIED="1678924536707" TEXT="Pixel-Breite daraus &#x27f9; Kalibrieren des ZoomWindow"/>
</node>
</node>
<node CREATED="1541861481967" ID="ID_1316730142" MODIFIED="1566955904369" TEXT="Feststellen der Canvas-Position">
@ -32881,6 +32934,7 @@
<node COLOR="#338800" CREATED="1562237357741" FOLDED="true" ID="ID_836338266" MODIFIED="1564954730183" TEXT="Prototyp / Evaluierung">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1562238962640" ID="ID_1949200690" MODIFIED="1678462240856" TEXT="#1201 Prototype: custom styled timeline profile">
<linktarget COLOR="#40a5bc" DESTINATION="ID_1949200690" ENDARROW="Default" ENDINCLINATION="-2003;-104;" ID="Arrow_ID_398104912" SOURCE="ID_1275966904" STARTARROW="None" STARTINCLINATION="2327;166;"/>
<linktarget COLOR="#3a84dd" DESTINATION="ID_1949200690" ENDARROW="Default" ENDINCLINATION="-483;0;" ID="Arrow_ID_16837481" SOURCE="ID_424517976" STARTARROW="None" STARTINCLINATION="615;0;"/>
<icon BUILTIN="button_ok"/>
</node>
@ -33689,6 +33743,23 @@
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
<node COLOR="#338800" CREATED="1678576309372" ID="ID_1568473205" MODIFIED="1678925367556" TEXT="konkrete CSS-Styles dokumentieren">
<arrowlink COLOR="#5f7783" DESTINATION="ID_1232986902" ENDARROW="Default" ENDINCLINATION="2218;-176;" ID="Arrow_ID_1708948555" STARTARROW="None" STARTINCLINATION="4285;319;"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1678925372624" ID="ID_348250165" MODIFIED="1678925428123">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
TiddlyWiki + <font face="Monospaced" color="#a63077">doc/technical/stage/style/Timeline.txt</font>
</p>
</body>
</html>
</richcontent>
</node>
</node>
</node>
<node CREATED="1561743807830" ID="ID_593477946" MODIFIED="1561898346705" TEXT="L&#xf6;sungsans&#xe4;tze">
<linktarget COLOR="#3078ce" DESTINATION="ID_593477946" ENDARROW="Default" ENDINCLINATION="-684;-128;" ID="Arrow_ID_845284570" SOURCE="ID_270618428" STARTARROW="None" STARTINCLINATION="-389;16;"/>
@ -46486,7 +46557,7 @@
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1678841457381" ID="ID_833023922" MODIFIED="1678841649108" TEXT="Breite an vorhandene Fensterbreite anmessen">
<linktarget COLOR="#748598" DESTINATION="ID_833023922" ENDARROW="Default" ENDINCLINATION="-1609;-94;" ID="Arrow_ID_1971623817" SOURCE="ID_81531339" STARTARROW="None" STARTINCLINATION="-140;338;"/>
<icon BUILTIN="flag-yellow"/>
<node CREATED="1678841652042" ID="ID_344873865" MODIFIED="1678841678052" TEXT="bezweifle ob das korrekt ankommt">
<node COLOR="#435e98" CREATED="1678841652042" ID="ID_344873865" MODIFIED="1678916366193" TEXT="bezweifle ob das korrekt ankommt">
<richcontent TYPE="NOTE"><html>
<head>
@ -46497,6 +46568,20 @@
</p>
</body>
</html></richcontent>
<icon BUILTIN="help"/>
</node>
<node COLOR="#338800" CREATED="1678916371168" ID="ID_1956699133" MODIFIED="1678916621731" TEXT="doch.... &#x27f6; works as designed">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
per Trace-Meldung &#252;berpr&#252;ft: calibrateExtension() ist so programmiert, da&#223; es die bestehende Metrik erh&#228;lt, sondern das ZoomWindow entsprechend verkleinert. Der Code verwendet bisher nur default-Werte f&#252;r die Timeline &#10233; die Metrik bleibt auf 25px/sec stehen, und damit wird die Gesamtl&#228;nge stets mindestens 575px sein; Ausnahme: wenn das Fenster ohnehin gr&#246;&#223;er ist...
</p>
</body>
</html></richcontent>
<icon BUILTIN="ksmiletris"/>
</node>
</node>
</node>
@ -47053,6 +47138,7 @@
</node>
</node>
<node CREATED="1664668670633" ID="ID_281557130" MODIFIED="1664668687274" TEXT="CSS-Schema f&#xfc;r das Lumiera-GTK-UI">
<linktarget COLOR="#8b1d60" DESTINATION="ID_281557130" ENDARROW="Default" ENDINCLINATION="-1401;-108;" ID="Arrow_ID_1840161927" SOURCE="ID_529832770" STARTARROW="None" STARTINCLINATION="-625;67;"/>
<node CREATED="1664668701652" ID="ID_1339380234" MODIFIED="1664668992057" TEXT="Einrichtung durch den UI-Manager">
<arrowlink COLOR="#4369a6" DESTINATION="ID_280366952" ENDARROW="Default" ENDINCLINATION="-1736;397;" ID="Arrow_ID_1332353653" STARTARROW="None" STARTINCLINATION="-2101;-134;"/>
<icon BUILTIN="info"/>
@ -47123,6 +47209,12 @@
</node>
</node>
</node>
<node CREATED="1678576343977" ID="ID_943672117" MODIFIED="1678576356597" TEXT="Konkret / speziell">
<node CREATED="1678576366604" ID="ID_1232986902" MODIFIED="1678576571070" TEXT="CSS-Schema zum Styling der Timeline">
<linktarget COLOR="#5f7783" DESTINATION="ID_1232986902" ENDARROW="Default" ENDINCLINATION="2218;-176;" ID="Arrow_ID_691307229" SOURCE="ID_650016552" STARTARROW="None" STARTINCLINATION="7697;843;"/>
<linktarget COLOR="#5f7783" DESTINATION="ID_1232986902" ENDARROW="Default" ENDINCLINATION="2218;-176;" ID="Arrow_ID_1708948555" SOURCE="ID_1568473205" STARTARROW="None" STARTINCLINATION="4285;319;"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#fefc4e" COLOR="#351d75" CREATED="1448070545132" HGAP="31" ID="ID_1410368513" MODIFIED="1557498707235" TEXT="Element" VSHIFT="-7">