diff --git a/src/gui/timeline/marker-widget.hpp b/src/gui/timeline/marker-widget.hpp index 63e014b8d..45ee015e3 100644 --- a/src/gui/timeline/marker-widget.hpp +++ b/src/gui/timeline/marker-widget.hpp @@ -40,7 +40,7 @@ #include "gui/gtk-base.hpp" #include "gui/model/widget.hpp" -#include "gui/widget/label-widget.hpp" +#include "gui/widget/element-box-widget.hpp" //#include "lib/util.hpp" @@ -65,7 +65,7 @@ namespace timeline { */ class MarkerWidget : public model::Widget - , public widget::LabelWidget + , public widget::ElementBoxWidget { MarkerKind kind_; string name_; diff --git a/src/gui/widget/label-widget.cpp b/src/gui/widget/element-box-widget.cpp similarity index 81% rename from src/gui/widget/label-widget.cpp rename to src/gui/widget/element-box-widget.cpp index 1882506df..7156a0e92 100644 --- a/src/gui/widget/label-widget.cpp +++ b/src/gui/widget/element-box-widget.cpp @@ -1,5 +1,5 @@ /* - LabelWidget - display an ID label, possibly with icon + ElementBoxWidget - fundamental UI building block to represent a placed element Copyright (C) Lumiera.org 2016, Hermann Vosseler @@ -24,13 +24,13 @@ /** @file label-widget.cpp ** Implementation details of the UI building block to display an ID label. ** - ** @todo WIP-WIP-WIP as of 12/2016 + ** @todo WIP-WIP-WIP as of 11/2018 ///////////////////////////////////////////////////////////////////////TICKET #1185 ** */ #include "gui/gtk-base.hpp" -#include "gui/widget/label-widget.hpp" +#include "gui/widget/element-box-widget.hpp" //#include "gui/ui-bus.hpp" //#include "lib/format-string.hpp" @@ -59,12 +59,12 @@ namespace widget { - LabelWidget::LabelWidget () + ElementBoxWidget::ElementBoxWidget () { } - LabelWidget::~LabelWidget() + ElementBoxWidget::~ElementBoxWidget() { } diff --git a/src/gui/widget/label-widget.hpp b/src/gui/widget/element-box-widget.hpp similarity index 76% rename from src/gui/widget/label-widget.hpp rename to src/gui/widget/element-box-widget.hpp index 904a4b5eb..530961ef0 100644 --- a/src/gui/widget/label-widget.hpp +++ b/src/gui/widget/element-box-widget.hpp @@ -1,8 +1,8 @@ /* - LABEL-WIDGET.hpp - display an ID label, possibly with icon + ELEMENT-BOX-WIDGET.hpp - fundamental UI building block to represent a placed element Copyright (C) Lumiera.org - 2016, Hermann Vosseler + 2018, Hermann Vosseler This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as @@ -21,7 +21,7 @@ */ -/** @file label-widget.hpp +/** @file element-box-widget.hpp ** Widget to render an ID label with associated icon. ** This is a UI building block used at various places, e.g. to show ** the name of a clip in the media bins or in the timeline, to indicate @@ -32,13 +32,13 @@ ** support for picking the icon and the indicator style based on some ** notion of _"type"._ ** - ** @todo WIP-WIP-WIP as of 12/2016 + ** @todo WIP-WIP-WIP as of 11/2018 ///////////////////////////////////////////////////////////////////////TICKET #1185 ** */ -#ifndef GUI_WIDGET_LABEL_WIDGET_H -#define GUI_WIDGET_LABEL_WIDGET_H +#ifndef GUI_WIDGET_ELEMENT_BOX_WIDGET_H +#define GUI_WIDGET_ELEMENT_BOX_WIDGET_H #include "gui/gtk-base.hpp" @@ -56,11 +56,11 @@ namespace widget { /** * @todo WIP-WIP as of 12/2016 */ - class LabelWidget + class ElementBoxWidget { public: - LabelWidget (); - ~LabelWidget(); + ElementBoxWidget (); + ~ElementBoxWidget(); private:/* ===== Internals ===== */ @@ -68,4 +68,4 @@ namespace widget { }}// namespace gui::widget -#endif /*GUI_WIDGET_LABEL_WIDGET_H*/ +#endif /*GUI_WIDGET_ELEMENT_BOX_WIDGET_H*/ diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 85fd96bf2..83c8b3293 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2691,7 +2691,7 @@ As starting point, {{red{in winter 2016/17}}} the old (broken) timeline panel wa After that initial experiments, my focus shifted to the still unsatisfactory top-level UI structure, and I am working towards an initial integration with Proc-Layer since then. -
+
//The representation of a [[media clip|Clip]] for manipulation by the user within the UI.//
 Within Lumiera, a clip is conceived as a //chunk of media,// which can be handled in compound. Clip as such is an abstract concept, which is treated with minimal assumptions...
 * we know that a clip has //media content,// which need not be uniform and can be inherently structured (e.g. several media, several channels, a processing function)
@@ -2723,7 +2723,7 @@ This creates a tension related to the kind of architecture we want to build with
 Starting from the architecture as predetermined by the UI-Bus, it is clear that we have to add a UI-Element for every tangible child entity represented in the (abstracted) model. And the parent entity receiving a diff and adding such a child element is also in charge of that element, controlling its lifecycle. Yet this child element is not necessarily bound to be a widget. This is our chance here: what "adding" means is completely within the scope of the parent element and basically an implementation detail. So the parent may create and own a tracker or controller object to stand for the clip, and the latter may create and adjust the actual widget in negotiation with a display strategy. So effectively we're introducing a //mediator,// which represents the clip (as far as the modelling is concerned) and which at the same time communicates with a global display manager. We call this mediating entity a ClipPresenter
 
 !!!how to carry out the clip appearances
-Initially, one could think that we'd need to build several widgets to realise the wide variety of clip appearances. But in fact it turns out that we're able to reshape a single base widget to encompass all the necessary presentation styles. This base widget is a simple, one-element container, with {{{Gtk::Frame}}} being the most obvious pick. This gives us already a rectangular covered space, and the ability to add a label widget, optionally with controlled alignment of the label. All the more elaborate presentation styles can be achieved by adding a canvas widget into this frame and then placing additional stuff on top of that. The only tricky part arises in overview display, when just some clip rectangle can stand-in for a whole series of clips, which themselves remain hidden as UI elements.
+Initially, one could think that we'd need to build several widgets to realise the wide variety of clip appearances. But in fact it turns out that we're able to reshape a single base widget to encompass all the presentation styles. Almost all of the necessary styles, to be more precise, omitting the mere overview drawing where several entities are combined into a single box. However, this basic [[element-box-widget|GuiElementBoxWidget]] can be generalised, and even used beyond the clip display itself. It is a simple, one-element container, with an Icon and a textual label. This gives us already a rectangular covered space, and the ability to include a menu and to control the alignment of the label. All the more elaborate presentation styles can be achieved by adding a canvas widget into this frame and then placing additional stuff on top of that. The only tricky part arises in overview display, when just some clip rectangle can stand-in for a whole series of clips, which themselves remain hidden as UI elements.
 
 A prime consideration regarding this whole clip presentation strategy is the performance concern. It is quite common for movie edits to encompass several hundred individual clips. Combined with several tracks and an elaborate audio edit, it may well happen that we end up with thousands of individual UI objects. If treated naively, this load might seriously degrade the responsiveness of the interface. Thus we need to care for the relevant infrastructure to enable optimisation of the display. For that reason, the memory footprint of the ClipPresenter and the basic widget has to be kept as small as possible. And moreover, since we do our own layout management in the timeline display, in theory it is possible //only to add// those widgets to the enclosing GTK container, which are //actually about to become visible.// (if we follow this approach, a problem yet to be solved is how to remove widgets falling out of sight, since removing N widgets easily turns into a quadratic operation).
 
@@ -3231,6 +3231,48 @@ Each top-level window //holds a single dock,// which in turn might hold several
 !!!Panel Locator
 In accordance with this structure, we introduce a central component, the {{{PanelLocator}}} -- to keep track of all {{{DockArea}}} elements within the UI. The latter are responsible for managing the docking panels //within a specific// top-level {{{WorkspaceWindow}}}.
 
+
+
+
+
//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)
+* a //Menu Button// -- in fact a small downward arrow, which can be flipped upwards (expand/collapse)
+* a //Text Label// designating the element
+
+This characteristic cadence of elements gives us a horizontal box with distinct extension, and an arrangement to attach menu actions and a possibly extended display style. This arrangement can be used for...
+* Markers
+* Elements in the Bins (Clips, Media, Effects, Assets....)
+* abridged display of Clips (and Effects)
+* the Effect-bar to mark the presence of an Effect
+* for the Track heads in the Timeline Header pane
+* for ~Clip-Placement and name
+
+→ see also [[Ticket #1185|https://issues.lumiera.org/ticket/1185]].
+
+!Properties
+* the Icon shall be easily configurable (from the coding view point, of course this is all hard wired in the code or the theme)
+** the default is to configure the ''Placement Icon''
+** alternatively a ~Stock-ID can be given
+* the horizontal extension is easy to control, through several options
+** natural extension; don't give any ''size request'', let GTK figure out the extension rather
+** set a fixed length-limit, causing the text label to be abridged eventually
+** proportional head-placement
+* the body may optionally hold another GTK widget, in which case the head-triplet aligns to the upper side
+
+We offer pre-arranged options for standard wiring of interaction response
+* when the Icon is a Placement, it will launch the [[Placement-Pop-up|GuiPlacementDisplay]] -- which in turn can be de-modalised, thereby allocating a place in the [[Property grid pane|GuiPropertyPane]]. When such a placement control already is open and allocated, the click to the placement icon will lead there.
+* in the most basic case, there is only one common binding, which is a signal, emitted when clicking on the icon or the menu button
+* yet there can be two distinct bindings (signals) for the icon and the button
+* the ''Expander'' (which is part of the UI-Element protocol) is pre-wired with the arrow on the menu button, to yield a visible clue for the expand/collapse state
+* each of the bindings can be easily replaced by a [[pop-up menu|GuiPopupMenu]]
+
+!!!proportional Head placement
+This behaviour pattern (see [[#1186|https://issues.lumiera.org/ticket/1186]]) is a distinguishing trait of the Lumiera timeline display. It indicates elements with a temporal extension surpassing the current display window. Such elements are typically represented by an {{{ElementBoxWidget}}} with an large horizontal extension. Yet when scrolling, the head-triplet shall always remain within the visible area, but it will slowly glide from one side to the other, thereby indicating the our relative position. This pattern of behaviour matters, since, together with the scolled content display, it creates the dominant movement when scrolling an extended timeline
+
+''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.
@@ -3393,15 +3435,24 @@ The most fundamental principle is that of ''subsidiarity'': we understand both & Based on these foundations, we shape and form the core part of the interface, which is the [[timeline display|GuiTimelineView]]
-
+
A cross-cutting and somewhat tricky concern is how to represent and expose the [[MObject Placements|Placement]] within the UI.
 For one, a Placement is a set of rules picked up from enclosing scopes -- and it is one of the most fundamental traits of Lumiera that the user is able to edit those placement rules. Yet the combination and final application of those rules also materialises itself into actual properties of the objects of the edit session -- most notably the time position of any element. Consequently, parts of the Placement are unfolded to appear as properties of the placed object, as far as the UI representation is concerned. However, Placement as a generic building block is prominently exposed, insofar pretty much every entity you'll see in the UI has the ability to "edit its placement". This is indicated by a characteristic Icon decoration, leading to a common placement editor, where the user can
 * see all the explicitly given locating pins
 * see the effective, resulting ExplicitPlacement
 * add and manipulate existing rules
 To support this generic setup, pretty much every UI element needs to be outfitted with a "placement" attribute, to reflect those distinct information to be exposed in aforementioned placement edit UI.
+→ see also [[Ticket #1188|https://issues.lumiera.org/ticket/1188]].
+
+
//Organisation of Pop-up menus in the Lumiera UI.//
+A pop-up is created on right click on the associated element, which thereby exposes its //methods for manipulation.// As such this arrangement incorporates the principle of ''object orientation'' into the interactive user interface.
+
+The foundation of population and display of pop-up menues is provided by GTK -- however the //»object orientation«// is our actual design concern here.
+
+{{red{OMG 11/2018 -- I have no idea where to start here...}}}
+
Starting up the GUI is optional and is considered part of the Application start/stop and lifecycle.
 * main and {{{lumiera::AppState}}} activate the lifecyle methods on the ~GuiSubsysDescriptor, accessible via the GuiFacade
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 50f931a66..564be6475 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -5378,7 +5378,7 @@
 
 
 
-
+
 
   
     
@@ -5408,13 +5408,14 @@
       
     
   
-
+
+
 
 
 
 
 
-
+
 
   
     
@@ -5441,7 +5442,8 @@
       
     
   
-
+
+
 
 
 
@@ -5456,7 +5458,7 @@
 
 
 
-
+
 
   
     
@@ -5466,7 +5468,8 @@
       vorbereitete Grundstrukturen für immer wiederkehrende Setups
     

   
-
+
+
 
 
 
@@ -5661,7 +5664,7 @@
 
 
 
-
+
 
   
     
@@ -5674,7 +5677,8 @@
       Im Zweifelsfall den GTK+ Inspector verwenden!
     

   
-
+
+
 
 
 
@@ -5693,7 +5697,7 @@
 
 
 
-
+
 
   
     
@@ -5703,7 +5707,8 @@
       CSS genügt
     

   
-
+
+
 
 
 
@@ -5716,7 +5721,7 @@
 
 
 
-
+
 
   
     
@@ -5751,7 +5756,8 @@
       }
     

   
-
+
+
 
 
 
@@ -5825,7 +5831,7 @@
 
 
 
-
+
 
   
     
@@ -5838,10 +5844,11 @@
       daß die alte, obsolete Timeline zurückgebaut ist
     

   
-
+
+
 
 
-
+
 
   
     
@@ -5857,7 +5864,8 @@
       bevor die Notification-Facade geöffnet werden konnte
     

   
-
+
+
 
 
 
@@ -5909,7 +5917,7 @@
 
 
 
-
+
 
   
     
@@ -5940,7 +5948,8 @@
       Allerdings habe ich an der Stelle immer noch GTK-Assertions
     

   
-
+
+
 
 
 
@@ -5988,7 +5997,7 @@
 
 
 
-
+
 
   
     
@@ -6016,7 +6025,8 @@
       ist, daß Gio::Application sofort auch gleich eine dBus-Verbindung hochfährt.
     

   
-
+
+
 
 
 
@@ -16627,7 +16637,7 @@
 
 
 
-
+
 
   
     
@@ -16643,7 +16653,8 @@
       und daher auf "inaktiv" geschaltet ist.
     

   
-
+
+
 
 
 
@@ -17033,7 +17044,7 @@
 
 
 
-
+
 
   
     
@@ -17043,7 +17054,8 @@
       ...denn das ist das vereinfachte Setup für "einfache" Applikationen
     

   
-
+
+
 
 
 
@@ -17419,7 +17431,7 @@
 
 
 
-
+
 
   
     
@@ -17429,9 +17441,10 @@
       das Diff wird auf den Platzhalter angewendet
     

   
-
+
+
 
-
+
 
   
     
@@ -17444,7 +17457,8 @@
       dann muß dieses automatisch deregistriert werden
     

   
-
+
+
 
 
 
@@ -17586,7 +17600,129 @@
 
 
 
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      d.h. das Widget unternimmt selber nichts, und überläßt GTK die Größenbestimmung
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      d.h. das Text-Label bekommt ggfs. eine Längenbeschränkung.
+    

+    

+      Und sonst wird er Körper/Hintergrund ausgedehnt
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      Vorgabe ist ein Fenster(=Intervall) und dessen Position relativ zum Widget-Start.
+    

+    

+      Das Widget bestimmt daraus selbständig
+    

+    
    
+      
  • 
+        wie das Fenster relativ zu seiner eigenen Ausdehnung liegt (Logik von Intervallen ist komplex!)
+      
    • 
+      
  • 
+        ob es im Besonderen in seinem Inneren liegt, und proportional wo
+      
    • 
+      
  • 
+        und wählt dem entsprechend die Platzierung des "Kopf"-Handles (Icon+Label)
+      
    • 
+    

+    

+      Das Resultat ist, daß der Kopf dynamisch und proportional mitrollt,
+    

+    

+      ähnlich wie das Handle einer Scrollbar. Damit bleibt der Kopf
+    

+    

+      stets zugreifbar, und gibt einen Hinweis auf die Gesamtlage.
+    

+    

+      Sehr wichtig für die Anzeige von langen Clips und Effekten.
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -17689,7 +17825,7 @@
 
 
 
-
+
 
   
     
@@ -17702,7 +17838,8 @@
       und welchen Teil des Verhaltens überlassen wir GTK
     

   
-
+
+
 
 
 
@@ -17743,7 +17880,7 @@
 
 
 
-
+
 
   
     
@@ -17759,7 +17896,8 @@
       Details im  TiddlyWiki....
     

   
-
+
+
 
 
 
@@ -17812,7 +17950,7 @@
 
 
 
-
+
 
   
     
@@ -17822,7 +17960,8 @@
       braucht feste Speicher-Addresse
     

   
-
+
+
 
 
 
@@ -17831,7 +17970,7 @@
 
 
 
-
+
 
   
     
@@ -17844,7 +17983,8 @@
       und sei es auch bloß über ein Interface!
     

   
-
+
+
 
 
 
@@ -17859,7 +17999,7 @@
 
 
 
-
+
 
   
     
@@ -17893,7 +18033,8 @@
       
     
   
-
+
+
 
 
 
@@ -17964,7 +18105,7 @@
 
 
 
-
+
 
   
     
@@ -17974,7 +18115,8 @@
       ...für die dritte Lösung, die Repräsentation bereits in der Session
     

   
-
+
+
 
 
 
@@ -18062,7 +18204,7 @@
 
 
 
-
+
 
   
     
@@ -18078,9 +18220,10 @@
       Implementiert würde sie vom jeweiligen Widget
     

   
-
+
+
 
-
+
 
   
     
@@ -18108,9 +18251,10 @@
       Der Dekorator würde also auf dem TreeMutator sitzen...
     

   
-
+
+
 
-
+
 
   
     
@@ -18129,9 +18273,10 @@
       Daher gibt es die matchSrc-Operation. Effektiv wird die aber nur bei einem Delete aufgerufen...
     

   
-
+
+
 
-
+
 
   
     
@@ -18152,7 +18297,8 @@
       
     
   
-
+
+
 
 
 
@@ -18230,7 +18376,7 @@
 
 
 
-
+
 
   
     
@@ -18240,7 +18386,8 @@
       d.h. eine LUID
     

   
-
+
+
 
 
 
@@ -18273,7 +18420,7 @@
 
 
 
-
+
 
   
     
@@ -18286,7 +18433,8 @@
       Irgend eine BareEntryID genügt
     

   
-
+
+
 
 
 
@@ -18350,7 +18498,7 @@
 
 
 
-
+
 
   
     
@@ -18360,13 +18508,14 @@
       ...abstraktes Interface
     

   
-
+
+
 
 
 
 
 
-
+
 
   
     
@@ -18382,7 +18531,8 @@
       um die Bindung herzustellen
     

   
-
+
+
 
 
 
@@ -19079,7 +19229,12 @@
 
 
 
-
+
+
+
+
+
+
 
 
 
@@ -19183,7 +19338,7 @@
 
 
 
-
+
 
   
     
@@ -19193,7 +19348,8 @@
       ...sie verwenden dann ein LabelWidget zur Darstellung
     

   
-
+
+
 
 
 
@@ -19203,11 +19359,19 @@
 
 
 
+
 
 
 
 
 
+
+
+
+
+
+
+
 
 
 
@@ -19293,7 +19457,7 @@
 
 
 
-
+
 
   
     
@@ -19309,7 +19473,8 @@
       Verwende das als Leitgedanke, um das Layout zu entwickeln
     

   
-
+
+
 
 
 
@@ -20666,7 +20831,7 @@
 
 
 
-
+
 
   
     
@@ -20684,10 +20849,11 @@
       
     
   
-
+
+
 
 
-
+
 
   
     
@@ -20702,7 +20868,8 @@
       
     
   
-
+
+
 
 
 
@@ -20716,7 +20883,7 @@
 
 
 
-
+
 
   
     
@@ -20741,7 +20908,8 @@
       
     
   
-
+
+
 
 
 
@@ -21009,7 +21177,7 @@
 
 
 
-
+
 
   
     
@@ -21028,7 +21196,8 @@
       erfordert bereits Kenntnis der Innereien
     

   
-
+
+
 
 
 
@@ -28086,7 +28255,7 @@
 
 
 
-
+
 
   
     
@@ -28099,11 +28268,12 @@
       Implementierung der real-world-Variante fehlt!
     

   
-
+
+
 
 
 
-
+
 
   
     
@@ -28119,7 +28289,8 @@
       wie Session- und State-Managment, Commands etc.
     

   
-
+
+
 
 
 
@@ -33414,7 +33585,7 @@
 
 
 
-
+
 
   
     
@@ -33435,7 +33606,8 @@
       
     
   
-
+
+
 
 
 
@@ -35839,7 +36011,7 @@
 
 
 
-
+
 
   
     
@@ -35870,7 +36042,8 @@
       Denn letzteres ist bei uns eine Grundannahme. Es gibt keine ungefähren Diffs!
     

   
-
+
+
 
 
 
@@ -38874,7 +39047,7 @@
 
 
 
-
+
 
   
     
@@ -38890,14 +39063,15 @@
       Ganz prominent fehlt hier also z.B: MIDI
     

   
-
+
+
 
 
 
 
 
 
-
+
 
   
     
@@ -38910,7 +39084,8 @@
       die Aufgrund von Klassifikationen automatisch bereits existieren
     

   
-
+
+
 
 
 
@@ -39771,7 +39946,7 @@
 
 
 
-
+
 
   
     
@@ -39784,7 +39959,8 @@
       sofern das Widget mit entsprechendem Modus eingefügt wurde
     

   
-
+
+
 
 
 
@@ -39817,7 +39993,7 @@
 
 
 
-
+
 
   
     
@@ -39830,7 +40006,8 @@
       context->add_class("ohMy");
     

   
-
+
+
 
 
 
@@ -39909,7 +40086,7 @@
 
 
 
-
+
 
   
     
@@ -39925,7 +40102,8 @@
       oder ist es eine Vererbungs-Hierarchie, wie sie für das CSS-Styling benötigt wird?
     

   
-
+
+
 
 
 
@@ -39946,7 +40124,7 @@
 
 
 
-
+
 
   
     
@@ -39970,7 +40148,8 @@
       
     
   
-
+
+
 
 
 
@@ -40021,7 +40200,7 @@
 
 
 
-
+
 
   
     
@@ -40040,7 +40219,8 @@
       Alles in ein Framework zwingen. Alternativlos, capisce?
     

   
-
+
+
 
 
 
@@ -40065,7 +40245,7 @@
 
 
 
-
+
 
   
     
@@ -40078,7 +40258,8 @@
       welche ggfs C++ - Exceptions fängt
     

   
-
+
+
 
 
 
@@ -40091,7 +40272,7 @@
 
 
 
-
+
 
   
     
@@ -40110,11 +40291,12 @@
       Nur das ist der Grund. Es geht gar nicht um die Event-Loop
     

   
-
+
+
 
 
 
-
+
 
   
     
@@ -40135,11 +40317,12 @@
       
     
   
-
+
+
 
 
 
-
+
 
   
     
@@ -40167,7 +40350,8 @@
       
     
   
-
+
+
 
 
 
@@ -40233,7 +40417,7 @@
 
 
 
-
+
 
   
     
@@ -40288,7 +40472,8 @@
       }
     

   
-
+
+
 
 
 
@@ -40302,7 +40487,7 @@
 
 
 
-
+
 
   
     
@@ -40369,7 +40554,8 @@
       }
     

   
-
+
+
 
 
 
@@ -40429,7 +40615,7 @@
 
 
 
-
+
 
   
     
@@ -40442,9 +40628,10 @@
       aber macht in etwa die gleichen Operationen
     

   
-
+
+
 
-
+
 
   
     
@@ -40463,7 +40650,8 @@
       Gtk-Main verwendet inzwischen den gleichen Mechanismus
     

   
-
+
+
 
 
 
@@ -40476,7 +40664,7 @@
 
 
 
-
+
 
   
     
@@ -40498,7 +40686,8 @@
       Das ist eine subtile Falle.
     

   
-
+
+
 
 
 
@@ -40517,7 +40706,7 @@
 
 
 
-
+
 
   
     
@@ -40540,7 +40729,8 @@
       alles das nicht aus dem GUI-Thread heraus geschieht
     

   
-
+
+
 
 
 
@@ -40596,7 +40786,7 @@
 
 
 
-
+
 
   
     
@@ -40606,9 +40796,10 @@
       ...ob beim Expand/Collapse das umschließende Widget resized werden soll
     

   
-
+
+
 
-
+
 
   
     
@@ -40618,12 +40809,13 @@
       ob eingeklappt oder ausgeklappt
     

   
-
+
+
 
 
 
 
-
+
 
   
     
@@ -40636,7 +40828,8 @@
       was dazu führt, daß das Kind stets allen verfügbaren Platz nimmt
     

   
-
+
+
 
 
 
@@ -40775,7 +40968,7 @@
 
 
 
-
+
 
   
     
@@ -40788,7 +40981,8 @@
       Siehe Beschreibung im Beispiel/Tutorial
     

   
-
+
+
 
 
 
@@ -40844,7 +41038,7 @@
 
 
 
-
+
 
   
     
@@ -40854,9 +41048,10 @@
       ....how does the event dispatching deal with partially covered widgets
     

   
-
+
+
 
-
+
 
   
     
@@ -40866,7 +41061,8 @@
       ...for embedded widgets
     

   
-
+
+
 
 
 
@@ -40899,7 +41095,7 @@
 
 
 
-
+
 
   
     
@@ -40912,7 +41108,8 @@
       i.e. the enclosing parent widget also gets a chance to redraw itself
     

   
-
+
+
 
 
 
@@ -40933,7 +41130,7 @@
 
 
 
-
+
 
   
     
@@ -40943,13 +41140,14 @@
       asked on stackoverflow...
     

   
-
+
+
 
 
 
 
 
-
+
 
   
     
@@ -40962,7 +41160,8 @@
       by printing values from the on_draw() callback
     

   
-
+
+
 
 
 
@@ -41098,7 +41297,7 @@
 
 
 
-
+
 
   
     
@@ -41126,7 +41325,8 @@
       Kind-Widgets noch gar nicht festgelegt war (denn das passiert erst beim draw).
     

   
-
+
+
 
 
 
@@ -41164,7 +41364,7 @@
 
 
 
-
+
 
   
     
@@ -41180,7 +41380,8 @@
       und auch ein Signal für Parse-Fehler anschließt
     

   
-
+
+
 
 
 
@@ -41207,7 +41408,7 @@
 
 
 
-
+
 
   
     
@@ -41225,7 +41426,8 @@
       Beachte: der Text-Cursor (Marker "insert") hat right gravity
     

   
-
+
+
 
 
 
@@ -41300,7 +41502,7 @@
 
 
 
-
+
 
   
     
@@ -41322,7 +41524,8 @@
       The grip is implemented as a GdlDockItemGrip
     

   
-
+
+
 
 
 
@@ -41403,7 +41606,7 @@
     

   
 
-
+
 
   
     
@@ -41413,9 +41616,10 @@
       kann eines der Templates im Zyklus vorrübergehend als "incomplete" gelten.
     

   
-
+
+
 
-
+
 
   
     
@@ -41437,7 +41641,8 @@
       Konsequenz: man wählt dann z.B. eine subtil falsche Spezialisierung.
     

   
-
+
+
 
 
 
@@ -41463,7 +41668,7 @@
 
 
 
-
+
 
   
     
@@ -41491,13 +41696,14 @@
       selber aus einem statischen Initialisierungs-Kontext heraus erfolgt.
     

   
-
+
+
 
 
 
 
 
-
+
 
   
     
@@ -41693,7 +41899,8 @@
         }
     

   
-
+
+
 
 
 
@@ -41935,7 +42142,7 @@
 
 
 
-
+
 
   
     
@@ -41960,9 +42167,10 @@
       Query<RES>::resolveBy
     

   
-
+
+
 
-
+
 
   
     
@@ -41997,14 +42205,15 @@
       sonst kommt Doxygen durcheinander
     

   
-
+
+
 
 
 
 
 
 
-
+
 
   
     
@@ -42026,7 +42235,8 @@
       wird hier kein Link erzeugt
     

   
-
+
+
 
 
 
@@ -42042,7 +42252,7 @@
 
 
 
-
+
 
   
     
@@ -42058,7 +42268,8 @@
       Die Icon-Größen ergeben sich aus den Boxes auf 'plate'
     

   
-
+
+
 
 
 
@@ -42073,7 +42284,7 @@
 
 
 
-
+
 
   
     
@@ -42083,7 +42294,8 @@
       ...im Besonderen die guten Diagramme für Pulse, ALSA und Jack
     

   
-
+
+
 
 
 
@@ -42208,7 +42420,7 @@
   
 
 
-
+
 
   
     
@@ -42231,10 +42443,11 @@
       "-Wl,-rpath-link=target/modules"
     

   
-
+
+
 
 
-
+
 
   
     
@@ -42244,14 +42457,15 @@
       laufen wieder alle
     

   
-
+
+
 
 
 
 
 
 
-
+
 
   
     
@@ -42261,7 +42475,8 @@
       test.sh Zeile 138
     

   
-
+
+
 
 
 
@@ -42305,7 +42520,7 @@
   
 
 
-
+
 
   
     
@@ -42315,12 +42530,13 @@
       und wir verbringen unsere Zeit mit contention
     

   
-
+
+
 
 
 
 
-
+
 
   
     
@@ -42330,7 +42546,8 @@
       ist klar, hab ich gebrochen
     

   
-
+
+
 
 
 
@@ -42346,7 +42563,7 @@
   
 
 
-
+
 
   
     
@@ -42359,7 +42576,8 @@
       Vorher hatte ich erste Kollisionen nach 25000 Nummern
     

   
-
+
+
 
 
 
@@ -42398,7 +42616,7 @@
 
 
 
-
+
 
   
     
@@ -42411,7 +42629,8 @@
       Aug 10 04:51:39 flaucher kernel: traps: test-suite[8249] trap int3 ip:7ffff7deb241 sp:7fffffffe5c8 error:0
     

   
-
+
+
 
 
 
@@ -42468,7 +42687,7 @@
 
 
 
-
+
 
   
     
@@ -42478,7 +42697,8 @@
       bison dejagnu flex gobjc libncurses5-dev libreadline-dev liblzma-dev libbabeltrace-dev libbabeltrace-ctf-dev python3-dev
     

   
-
+
+
 
 
 
@@ -42494,7 +42714,7 @@
 
 
 
-
+
 
   
     
@@ -42528,7 +42748,8 @@
       au weia LEUTE!
     

   
-
+
+
 
 
 
@@ -42552,7 +42773,7 @@
 
 
 
-
+
 
   
     
@@ -42568,10 +42789,11 @@
       und tatsächlich: das ist daneben, GCC hat Recht!
     

   
-
+
+
 
 
-
+
 
   
     
@@ -42581,7 +42803,8 @@
       aktualisieren und neu bauen
     

   
-
+
+
 
 
 
@@ -42601,7 +42824,7 @@
   
 
 
-
+
 
   
     
@@ -42611,7 +42834,8 @@
       wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird.
     

   
-
+
+
 
 
 
@@ -42645,7 +42869,7 @@
 
 
 
-
+
 
   
     
@@ -42658,9 +42882,10 @@
       Ich meine also: zu Beginn vom Build sollte das Buildsystem einmal eine Infozeile ausgeben
     

   
-
+
+
 
-
+
 
   
     
@@ -42670,7 +42895,8 @@
       ...denn die stören jeweils beim erzeugen eines Hotfix/Patch im Paketbau per dpkg --commit
     

   
-
+
+
 
 
 
@@ -42717,7 +42943,7 @@
 
 
 
-
+
 
   
     
@@ -42727,11 +42953,12 @@
       Doku durchkämmen nach Müll
     

   
-
+
+
 
 
 
-
+
 
   
     
@@ -42744,10 +42971,11 @@
       WICHTIG: keine vorgreifende Infor publizieren!!!!!
     

   
-
+
+
 
 
-
+
 
   
     
@@ -42763,7 +42991,8 @@
       insgesamt sorgfältig durchlesen
     

   
-
+
+
 
 
 
@@ -42773,7 +43002,7 @@
 
 
 
-
+
 
   
     
@@ -42783,7 +43012,8 @@
       knappe Kennzeichnung des Releases in den Kommentar
     

   
-
+
+
 
 
 
@@ -42791,7 +43021,7 @@
 
 
 
-
+
 
   
     
@@ -42810,7 +43040,8 @@
       denn wir wollen keine DEB-Info im Master haben!
     

   
-
+
+
 
 
 
@@ -42823,7 +43054,7 @@
 
 
 
-
+
 
   
     
@@ -42836,7 +43067,8 @@
       die unmittelbaren Release-Dokumente durchgehen
     

   
-
+
+
 
 
 
@@ -42850,7 +43082,7 @@
 
 
 
-
+
 
   
     
@@ -42863,7 +43095,8 @@
       Sollte konfliktfrei sein
     

   
-
+
+
 
 
 
@@ -42886,7 +43119,7 @@
 
 
 
-
+
 
   
     
@@ -42896,7 +43129,8 @@
       ...das heißt bauen und hochladen
     

   
-
+
+
 
 
 
@@ -42950,7 +43184,7 @@
 
 
 
-
+
 
   
     
@@ -42963,9 +43197,10 @@
       unter Debian/Jessie wird das ignoriert
     

   
-
+
+
 
-
+
 
   
     
@@ -42991,7 +43226,8 @@
       Die Wahrscheinlichkeit, daß irgend jemand Lumiera unter Ubuntu/Trusty installieren möchte, erscheint mir akademisch
     

   
-
+
+
 
 
 
@@ -43017,7 +43253,7 @@
 
 
 
-
+
 
   
     
@@ -43027,7 +43263,8 @@
       in lib/hash-standard.hpp
     

   
-
+
+
 
 
 
@@ -43042,7 +43279,7 @@
 
 
 
-
+
 
   
     
@@ -43062,7 +43299,8 @@
       es gibt Probleme beim Linken mit den Boost-Libraries, die auf Ubuntu/wily mit gcc-5 gebaut sind.
     

   
-
+
+
 
 
 
@@ -43070,7 +43308,7 @@
 
 
 
-
+
 
   
     
@@ -43080,7 +43318,8 @@
       Wichtig: hier nur was wirklich gebaut ist und funktioniert!
     

   
-
+
+
 
 
 
@@ -43104,7 +43343,7 @@
 
 
 
-
+
 
   
     
@@ -43120,7 +43359,8 @@
       bestehen, aber irgendwann müssen wir das schon glattziehen
     

   
-
+
+
 
 
 
@@ -43158,7 +43398,7 @@
   
 
 
-
+
 
   
     
@@ -43168,7 +43408,8 @@
       seit gcc-4.8 ist kein static_assert mehr in der STDlib
     

   
-
+
+
 
 
 
@@ -43210,7 +43451,7 @@
 
 
 
-
+
 
   
     
@@ -43256,10 +43497,11 @@
       END
     

   
-
+
+
 
 
-
+
 
   
     
@@ -43269,11 +43511,12 @@
       for I in `seq 1 50`; do target/test-suite CallQueue_test; done
     

   
-
+
+
 
 
 
-
+
 
   
     
@@ -43289,7 +43532,8 @@
       und eine Doxygen-Seite im Browser geladen
     

   
-
+
+
 
 
 
@@ -43310,7 +43554,7 @@
 
 
 
-
+
 
   
     
@@ -43320,7 +43564,8 @@
       weil sich die Threads gegenseitig ihre Counter inkrementieren.
     

   
-
+
+