//A building block used pervasively throughout the Lumiera UI to represent a named entity.//
This widget presents a horizontally extended body, which holds a characteristic ''Head-Triplet'' of visual Elements:
* an //Icon// to create the visual anchor point. In many cases, this will be ''the Placment Icon'' (a hallmark of Lumiera's UI)
@@ -3282,6 +3282,22 @@ This behaviour pattern (see [[#1186|https://issues.lumiera.org/ticket/1186]]) is
''Technically'', this has to be build as a self-contained component, which can be unit-tested. The input and reference is a "Window" (in fact an interval) together with its start position //relative// to the element's own start position. The component has to derive from this input the actual relational configuration of the window's extension with respect to its own extension. For context, the //window// corresponds to the visible area, which can be larger, smaller disjoint, partially overlapping and fully contained. Please note that ''handling the relations of intervals is a notoriously challenging problem.''
Especially when the component determines a placement of the //window// within its own extension, it has to derive a proportional placement position, which can be used to arrange the head-triplet of the {{{EventBoxWidget}}}. This proportional placement needs to reflect the location of the window within the overall extension, similar to the hand of a scrollbar. However, when the extension of the head-triplet, together with its placement disallows to show the the triplet unclipped, the triplets shall just be clipped naturally. Ideally, there would be a soft graceful transition between those two representation modes.
+
+!!!constrained Widget size
+When used as Clip display on a timeline canvas with calibrated time axis, the requirement arises to confine a GTK widget to a pre established size constraint. This requirement is problematic, as it stands in ''direct contradiction'' to ''GTK's fundamental design'': Elements are never to be positioned explicitly, but rather the layout will flow into balance, factoring in the specific font, language support and interface styling and theming. GTK does not provide any API to set layout explicitly — not even for special corner cases.
+Thus, if we intend to bring a custom widget into compliance with our contextual size constraints, the only solution is to //make the GTK layout engine turn out the desired extension allocation// for this custom widget. An detailed survey of the GTK implementation reveals the possible extension points, were such a layout manipulation could be injected.
+* some amount of screen extension is allocated by the framework or by a container widget for its children
+* this happens on first "realisation" of the Widget, or later, when a resize request is processed and the layout cache invalidated
+* the entry point is {{{Gtk::Widget::size_allocate()}}} (possibly with an additional "baseline" value)
+* the implementation first queries the widget for its preferences
+*# first, the layout trend is determined: either width-for-given-height, or height-for-given-width
+*# then, the widget is queried for its preference in the leading dimension
+*# followed by a call to the widget's width-for-given-height, or height-for-given-width implementation
+* the resulting desired ("natural") size allocation is then adjusted by widget decoration and finally passed to the widget for storage and use
+It turns out that the GTK layout management implementation always observes the widget's preferred extension, but possibly expands the allocation to fill additional space. And the standard implementation of {{{Gtk::Widget}}} in turn delegates those queries to the ''GTK CSS Gadget'' — which is a mapping of the hierarchical widget structure into CSS layout nodes.
+
+So the seemingly ''optimal leverage point'' is to ''return our pre established size constraint as result'' from these query functions — which can be overridden in the Gtkmm C++ implementation through the {{{Gtk::Widget::get_preferred_width_vfunc()}}} and {{{Gtk::Widget::get_preferred_height_for_width_vfunc()}}}. However, since GTK assumes these values to be sane and sufficient for a proper realisation of any embedded content, at this point we get the responsibility to control and reduce the embedded child widget's extension to bring them into compliance. Failing to do so will lead to garbled drawing on screen.
+Our solution approach is to watch the results returned by the default implementation and possibly to hide content until the remaining content conforms to the size constraint; after that, we can return //exactly our calibrated size// and expect GTK to observe this request, passing it down to embedded widgets reduced by style decorations.
+ veränderte Menü-Steuerung bei derartiger Degradierung +
+ ++ das bedeutet: es ist Aufgabe eines übergeordneten Layout-Managers, dann auch ein reduziertes Display zu schalten; das ElementBoxWidget kann davon ausgehen, den minimal benötigten Platz auch zu bekommen (size request) +
+ +
- das ist eine Flag in der privaten Widget-Struktur. Keine Ahnung was das bedeutet.
Und übrigens: sichtbar muß das Widget auch noch sein...
-
- also stellt eigentlich grade nicht die versprochene Logik bereit -
- -- danach noch die adjust_baseline_allocation -
- -- also entweder in horizontaler, oder in vertikaler Richtung -
- -
+ If the question is more than 365 days old, and ...
+
+ weil dies die einzige Info ist, +
++ welche direkt vom Widget abgefragt wird, +
++ im Zuge der Layout-Berechnung +
+ ++ setzt bei Bedarf ein queue_resize ab +
+ ++ danach: priv->resize_needed = TRUE +
+ ++ alle Fäden laufen zusammen bei.... +
++ gtk_widget_size_allocate_with_baseline +
+ ++ ...da Funktionen irgendwo dann an Funktionspointer zugewiesen werden für "virtuelle Funktionen" +
+ ++ wird im class-init mit der jeweiligen konkreten Implementierung belegt, z.b. gtk_button_size_allocate +
+ +
+ das ist eine Flag in der privaten Widget-Struktur. Keine Ahnung was das bedeutet.
Und übrigens: sichtbar muß das Widget auch noch sein...
+
+ * Gets whether the widget prefers a height-for-width layout +
++ * or a width-for-height layout. +
++ * +
++ * #GtkBin widgets generally propagate the preference of +
++ * their child, container widgets need to request something either in +
++ * context of their children or in context of their allocation +
++ * capabilities. +
+ ++ also stellt eigentlich grade nicht die versprochene Logik bereit +
+ ++ danach noch die adjust_baseline_allocation +
+ ++ also entweder in horizontaler, oder in vertikaler Richtung +
+ ++ /* +
++ * Gadgets are 'next-generation widgets' - they combine a CSS node +
++ * for style matching with geometry management and drawing. Each gadget +
++ * corresponds to 'CSS box'. Compared to traditional widgets, they are more +
++ * like building blocks - a typical GTK+ widget will have multiple gadgets, +
++ * for example a check button has its main gadget, and sub-gadgets for +
++ * the checkmark and the text. +
++ * +
++ * Gadgets are not themselves hierarchically organized, but it is common +
++ * to have a 'main' gadget, which gets used by the widgets size_allocate, +
++ * get_preferred_width, etc. and draw callbacks, and which in turn calls out +
++ * to the sub-gadgets. This call tree might extend further if there are +
++ * sub-sub-gadgets that a allocated relative to sub-gadgets. In typical +
++ * situations, the callback chain will reflect the tree structure of the +
++ * gadgets CSS nodes. +
++ * +
++ * Geometry management - Gadgets implement much of the CSS box model for you: +
++ * margins, border, padding, shadows, min-width/height are all applied automatically. +
++ * +
++ * Drawing - Gadgets implement standardized CSS drawing for you: background, +
++ * shadows and border are drawn before any custom drawing, and the focus outline +
++ * is (optionally) drawn afterwards. +
++ * +
++ * Invalidation - Gadgets sit 'between' widgets and CSS nodes, and connect +
++ * to the nodes ::style-changed signal and trigger appropriate invalidations +
++ * on the widget side. +
++ */ +
+ ++ Hier steckt die Implementierung, und zwar die Kernimplementierung der Platzzuteilungs-Logik von GTK +
+ ++ min_size = get_number (style, GTK_CSS_PROPERTY_MIN_WIDTH); +
++ min_for_size = get_number (style, GTK_CSS_PROPERTY_MIN_HEIGHT); +
+ ++ basierend auf der Widget-Struktur, welche in Widget-Paths übersetzt wurde +
+ ++ Keine gute Idee: diese Funtktion wird verwendet, um die Dekoration zu entfernen, und Stil-Anpassungen zu machen; sie sollte daher besser als pure function betrachtet werden +
+ +