From 45b3a990f28a52c331590abae0cea36cc7c790d8 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 31 Aug 2017 20:15:52 +0200 Subject: [PATCH] DemoGuiRoundtrip: add new dock for UI experiments (#1099) ...after investigating problems related to the management of docking pane contents --- .../icons/prerendered/16x16/panel-infobox.png | Bin 0 -> 4421 bytes src/gui/ctrl/actions.hpp | 16 ++ src/gui/panel/infobox-panel.cpp | 88 ++++++++++ src/gui/panel/infobox-panel.hpp | 71 ++++++++ src/gui/widget/video-display-widget.cpp | 1 + src/gui/widget/video-display-widget.hpp | 9 +- src/gui/workspace/panel-manager.cpp | 4 +- src/gui/workspace/style-manager.cpp | 1 + wiki/renderengine.html | 35 +++- wiki/thinkPad.ichthyo.mm | 154 ++++++++++++++++-- 10 files changed, 355 insertions(+), 24 deletions(-) create mode 100644 data/icons/prerendered/16x16/panel-infobox.png create mode 100644 src/gui/panel/infobox-panel.cpp create mode 100644 src/gui/panel/infobox-panel.hpp diff --git a/data/icons/prerendered/16x16/panel-infobox.png b/data/icons/prerendered/16x16/panel-infobox.png new file mode 100644 index 0000000000000000000000000000000000000000..adb1517f5ad45e0476162e0af32424da9f058d52 GIT binary patch literal 4421 zcmeHKYdDnK9)G*I4I@OxrHt`(h&?l!reZQN%#fX7BKKP}V}^;j7&B%V36WdwluL?K zqS~^{t!N`6wMSbzG>A$hAt?&wj84x!U(T04oDb)Dto5vSz3cz}*6;nV-&)WA`LAS> zqa7He4FUiFY<~dnEbUcRo4l;_sW-Pm1^}5ok%v8a&SU|U!)4PMAv7p2f3H?YwZ7%f3Ib9=OSNg;M{rgrVP3Gy05|-ogD)i zEW7gYsmB?e%7z`X4O=7X-rcGqO1f#$UgB>v<7zbULhzQ%LmQT34f>*5k9!=lP!Y~* zmAxDgaqnew#7|nkDNaA)M;gpv?t});)h@XkpGp&1H-_GtQr|z$Lh)RtPAzlq_2ncx z)la&L*une)gZvaa@~uyo#XWowdV&N^yzFUZayW}7%wL_)sJ?mCv@P36xy!HdYSo`6eT|M^$5C8+~ucF82vSWLS9T# z(c3gvFzb~5@X(Awd-63upLJ(+%)t4QYj|BQ-ZmFUqq;LPd#3<({cr&Cfz)jKAr|Ht>X_7AW_@01RD5$^36L;iT%gQs z%uul#N=gfiAM?>1M3vQ8C5;%Q*x5B${W2D_tm-yOQr>?1IxLqjDNjz$rdKM9ME5{Ulf|9O~@{j~5Or4~=B|ihdK1ttWu1?^P(ppu@ zdq_$ku7M`TSAxx5a@)K4Gkj>!y{kZfXqY5cnyBUK@t5#5nE57@hPSJkSfJ z*?)lBKAW7GyfNL6Qo(v>#xWegLidua4X@}nhJ|(fceRc5%i1#j_d+{+m4n?>>b(p; zHBZ)Fp!@a*sm*ITP2P_+PtVYJJfLx}a91He^wq6kWo?ETn+X|xxxNJhv8qs-!`&^d z=ARj(A+V=w&uq@hsdYNOu0ne`*@Um&yLqGo{Nz}_39(oa-aM~s<5x1+&Q3G@q|;Dl zpQ_c^3)yqTcBt)3(qcB2Bu=$xds0*Bti>z7dc5l_&RxRYcFLZ$@dDG{9NK9+Dl-l}~qT zu{TDwni^6h7xty`%iW&g{ZDh_hB92b4thDZhXlxXja(d^i~9Ibk?J=ozvD&P&1nMT z3t#6&x58J}Swir!o}2L=X#efGpWJZ%8Dj#&yAw%W;<>o7Xu%#}<1d*XF9E_)1J<`N)$z3^WL;SS0@{vGy+ol*9(TYJ+Pip<*8@npw z1s*m-kQMpcjHvRF&e{8NGQ?ax@6OKsVK$#tkBm26#)D^^1GkTRL*@pAgAYcYCtdR= zCgX4ulr395(?2A%snxdiz7o0=`6^oavcb*$3;XVumxX>C^y~3V?0*iLEc!%`es0A| zf3H~S{;qHAc(LT!9CkMXFAb!W{~AFV93FKwf?|_#pk^zj^)nHK^O<<^&0)rTkN2jp zmU#(oINq(vXh}N!a%uiqAIC55*Mgjso?5r6Lb}$gEHSXU@TIb(*{2>K`LN zycYq0!cm4aUV9K7FjO`ZK@MP3Xb2&bBXt7+EG&f_GBudSgHmXL3>FqPbLS5jlo5c1 zx$h>L5;-=sAjW}6F3ly<@h~+qm}(vXv)m7|5MrbROd5|26*5CuVHhD6_MI0aeP1;r zVbJdoUN9EsK_o$K*jySEjX)zz;RGQg90l7Cf?99`=on|b?GFm+2n!41@i-VHQXmi@ z1iKJyZXj}}xw$#g6oo{g;8FxUEP}-&3*oFVgH?)ubKq%VRIXGz2Ac(4$4C zlYWQ(AP=Da&CTI+L%uTyP?59{8k5H2g&}t$b|Syy1E?5VHkV13&Sx;mfixtC6$nGF zdW-zwu5|Utzn8!2!~edl{p6=KUXyE0uAfrir@(8cYfY}7QsAe+Yp3h~OD@oV5-1u= znl%Ze=@GCJVoE3VldgEB zV8PveF}s@NL)m+0X3g~_d*bNP7J%_=m)*JH=;ql1#mtG5 zbPXAq?A(v-sM$oPey(Z^&^deuZ6epb?L@ai)KsiH`XSV{S9Abd_^J3sp6}8;XJJwI z%Gicx=GK8yNPH)5^q+lYDNzEbB{IGGtH|>$&xTRBNGO>-6ZqKU&IT-RdgImN@(mST za<&D3NGOuJ?H&hjQ(}7#(4aBkp^OzwiApOc0vhvRAPw*aDV!{e1t!>AdyPNC6D&signal_toggled().connect ( [&]() { onMenu_view_assets(); }); actionGroup->add(assetsPanelAction); + infoboxPanelAction = ToggleAction::create("ViewInfoBox", StockID("panel_infobox")); + infoboxPanelAction->signal_toggled().connect ( [&]() { onMenu_view_infobox(); }); + actionGroup->add(infoboxPanelAction); + timelinePanelAction = ToggleAction::create("ViewTimeline", StockID("panel_timeline")); timelinePanelAction->signal_toggled().connect( [&]() { onMenu_view_timeline(); }); actionGroup->add(timelinePanelAction); @@ -181,6 +185,7 @@ namespace ctrl { + @@ -314,6 +319,16 @@ namespace ctrl { unimplemented ("view assets"); } + void + onMenu_view_infobox() + { + /////////////////////////////////////////////////////////////////////////////////////TODO defunct since GTK-3 transition + //if(!is_updating_action_state) + // workspaceWindow.infoboxPanel->show( + // infoboxPanelAction->get_active()); //////global -> InteractionDirector + unimplemented ("view infobox"); + } + void onMenu_view_timeline() { @@ -347,6 +362,7 @@ namespace ctrl { Glib::RefPtr actionGroup; Glib::RefPtr assetsPanelAction; + Glib::RefPtr infoboxPanelAction; Glib::RefPtr timelinePanelAction; Glib::RefPtr viewerPanelAction; diff --git a/src/gui/panel/infobox-panel.cpp b/src/gui/panel/infobox-panel.cpp new file mode 100644 index 000000000..cb4ada655 --- /dev/null +++ b/src/gui/panel/infobox-panel.cpp @@ -0,0 +1,88 @@ +/* + InfoBoxPanel - A dockable panel to expose information and parameters + + Copyright (C) Lumiera.org + 2017, 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 + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + + +/** @file infobox-panel.cpp + ** Implementation of a (dockable) panel to display and manipulate parameters. + */ + +#include "gui/gtk-base.hpp" +#include "gui/panel/infobox-panel.hpp" + +namespace gui { +namespace panel{ + + InfoBoxPanel::InfoBoxPanel (workspace::PanelManager& panelManager, Gdl::DockItem& dockItem) + : Panel(panelManager, dockItem, getTitle(), getStockID()) + , twoParts_(Gtk::ORIENTATION_VERTICAL) + , buttons_() + , frame_("UI Integration Experiments") + , scroller_() + { + twoParts_.pack_start(frame_); + twoParts_.pack_start(buttons_, Gtk::PACK_SHRINK); + + buttons_.set_layout(Gtk::BUTTONBOX_START); + + // buttons to trigger experiments + button_1_.set_label("_bang"); + button_1_.set_use_underline(); + button_1_.set_tooltip_markup("Experiment 1:\ntrigger Proc-GUI roundtrip"); + button_1_.signal_clicked().connect( + mem_fun(*this, &InfoBoxPanel::experiment_1)); + buttons_.add(button_1_); + //(End)buttons... + + frame_.add(scroller_); + frame_.set_border_width(5); + + scroller_.set_shadow_type(Gtk::SHADOW_NONE); + scroller_.set_border_width(10); +// scroller_.add(canvas_);///////////////////////////TODO add text display box here... + + // show everything.... + this->add(twoParts_); + this->show_all(); + } + + const char* + InfoBoxPanel::getTitle() + { + return _("InfoBox"); + } + + const gchar* + InfoBoxPanel::getStockID() + { + return "panel_infobox"; + } + + + + void + InfoBoxPanel::experiment_1() + { + frame_.set_label("Experiment 1... BANG"); + } + + +}}// namespace gui::panel diff --git a/src/gui/panel/infobox-panel.hpp b/src/gui/panel/infobox-panel.hpp new file mode 100644 index 000000000..83c74dea7 --- /dev/null +++ b/src/gui/panel/infobox-panel.hpp @@ -0,0 +1,71 @@ +/* + infobox-panel.hpp - A dockable panel to expose information and parameters + + Copyright (C) Lumiera.org + 2017, 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 + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +/** @file infobox-panel.hpp + ** A (dockable) panel to display and manage information and parameters. + ** Such an »Info Box« typically exposes detail settings from some other component + ** currently selected, and allows to access those in a non modal fashion. + ** + ** @todo as of 8/2017 this is (ab)used as space for UI / Proc-Layer integration experiments + */ + + + +#ifndef GUI_PANEL_INFOBOX_PANEL_H +#define GUI_PANEL_INFOBOX_PANEL_H + + +#include "gui/panel/panel.hpp" + +namespace gui { +namespace panel{ + + class InfoBoxPanel + : public Panel + { + public: + /** Build a new InfoBox-Panel + * @param PanelManager The owner panel manager widget. + * @param DockItem The GdlDockItem that will host this panel. + * + * @todo as of 8/2017 this is placeholder code for UI experiments... + */ + InfoBoxPanel (workspace::PanelManager&, Gdl::DockItem&); + + + static const char* getTitle(); ///< @deprecated need better design of the PanelManager /////TICKET #1026 + static const gchar* getStockID(); + + private: + Gtk::Box twoParts_; + Gtk::ButtonBox buttons_; + Gtk::Button button_1_; + Gtk::Frame frame_; + Gtk::ScrolledWindow scroller_; + + void experiment_1(); + }; + + +}}// namespace gui::panel +#endif /*GUI_PANEL_INFOBOX_PANEL_H*/ diff --git a/src/gui/widget/video-display-widget.cpp b/src/gui/widget/video-display-widget.cpp index 00664f139..cb0beb506 100644 --- a/src/gui/widget/video-display-widget.cpp +++ b/src/gui/widget/video-display-widget.cpp @@ -23,6 +23,7 @@ /** @file video-display-widget.cpp ** Implementation of video display, embedded into the UI. + ** @deprecated defunct since the transition to GTK-3 */ diff --git a/src/gui/widget/video-display-widget.hpp b/src/gui/widget/video-display-widget.hpp index 451bc4074..4cc35d33a 100644 --- a/src/gui/widget/video-display-widget.hpp +++ b/src/gui/widget/video-display-widget.hpp @@ -23,6 +23,7 @@ /** @file video-display-widget.hpp ** Widget to create a video display embedded into the UI + ** @deprecated defunct since the transition to GTK-3 */ @@ -39,7 +40,13 @@ using namespace gui::output; ////////////////////////////////////////////////// namespace gui { namespace widget { - + + /** + * @todo the first UI draft included a video displayer widget library implementation, + * Unfortunately, this became defunct with the switch to GTK-3. And a fun fact is, + * even while Lumiera is a video editing application, we did not yet reach the state + * as to care for video display ourselves. Someone (TM) need to care for this! + */ class VideoDisplayWidget : public Gtk::DrawingArea { diff --git a/src/gui/workspace/panel-manager.cpp b/src/gui/workspace/panel-manager.cpp index 9a027b323..9d2cd1481 100644 --- a/src/gui/workspace/panel-manager.cpp +++ b/src/gui/workspace/panel-manager.cpp @@ -31,6 +31,7 @@ #include "gui/panel/assets-panel.hpp" #include "gui/panel/viewer-panel.hpp" +#include "gui/panel/infobox-panel.hpp" #include "gui/panel/timeline-panel.hpp" #include "gui/panel/timeline-panel-obsolete.hpp" @@ -47,6 +48,7 @@ namespace workspace { PanelManager::panelDescriptionList[] = { PanelManager::Panel(), PanelManager::Panel(), + PanelManager::Panel(), PanelManager::Panel(), PanelManager::Panel() }; @@ -236,7 +238,7 @@ namespace workspace { { ///////////////////////////////TICKET #1026 : code smell, use types directly instead panel::Panel* assetsPanel = createPanel_by_name("AssetsPanel"); - panel::Panel* viewerPanel = createPanel_by_name("ViewerPanel"); + panel::Panel* viewerPanel = createPanel_by_name("InfoBoxPanel"); panel::Panel* timelinePanel = createPanel_by_name("TimelinePanel"); dock_.add_item(assetsPanel->getDockItem(),Gdl::DOCK_LEFT); diff --git a/src/gui/workspace/style-manager.cpp b/src/gui/workspace/style-manager.cpp index 80f2a1f6f..81b044ce9 100644 --- a/src/gui/workspace/style-manager.cpp +++ b/src/gui/workspace/style-manager.cpp @@ -152,6 +152,7 @@ namespace workspace { addStockIconSet(factory, "panel-assets", "panel_assets", _("_Assets")); addStockIconSet(factory, "panel-viewer", "panel_viewer", _("_Viewer")); + addStockIconSet(factory, "panel-infobox", "panel_infobox", _("_InfoBox")); addStockIconSet(factory, "panel-timeline", "panel_timeline",_("_Timeline")); addStockIconSet(factory, "panel-timeline", "panel_timeline_obsolete",_("_ZombieTimeline")); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index a6f0aca07..4afe7223d 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2522,7 +2522,7 @@ we need a test setup for this investigation. * realistic: shall reflect the situation in our actual UI -
+
//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)
@@ -2535,7 +2535,7 @@ To start with, a clip can be rendered in ''abridged form'', which means that the
 
 The next step in a series of progressively more detailed clip representations is the ''compact form'', which still focuses on handling the clip as an unit, while at least indicating some of the inherent structuring. Essentially, the clip here is represented as a //strip of rendered preview content,// decorated with some overlays. One of these overlays is the //ID pane,// which resembles the arrangement known from the abridged form: The icon here is always the [[Placement]] icon, followed by the expand widget and the ID label. Again, this pane is aligned such as to remain in sight. Then, there is a pair of overlays, termed the //boundary panes,// which indicate the begin and the end of the clip respectively. Graphically, these overlays should be rendered in a more subtle way, just enough to be recognisable. The boundary panes are the attachment areas for //trimming gestures,// as opposed to moving and dragging the whole clip or shuffle editing of the content. Moreover, these boundary panes compensate for the alignment of the ID pane, which mostly keeps the latter in sight. As this might counterfeit the visual perception of scrolling, the boundary panes serve to give a clear visual clue when reaching the boundary of an extended clip. Optionally, another overlay is rendered at the upper side of the clip's area, to indicate attached effect(s). It is quite possible for these effect decorations not to cover the whole temporal span of the clip.
 
-A yet more detailed display of the clip's internals is exposed in the ''expanded form.'' Here, the clip is displayed as an window pane holding nested clip displays, which in turn might again be abridged, compact or ({{red{maybe 11/16}}}) even expanded. This enclosing clip window pane should be rendered semi transparent, just to indicate the enclosing whole. The individual clip displays embedded therein serve to represent individual media parts or channels, or individual attached effects. Due to the recursive nature of Lumiera's HighLevelModel, each of these parts exposes essentially the same controls, allowing to control the respective aspects of the part in question. We may even consider {{red{unclear as of 11/16}}} to allow accessing the parts of a VirtualClip, this way turning the enclosing clip into a lightweight container ({{red{11/2016 give proper credit for this concept! Who proposed this initially in 2008? was this Thosten Wilms?}}}
+A yet more detailed display of the clip's internals is exposed in the ''expanded form.'' Here, the clip is displayed as a window pane holding nested clip displays, which in turn might again be abridged, compact or ({{red{maybe 11/16}}}) even expanded. This enclosing clip window pane should be rendered semi transparent, just to indicate the enclosing whole. The individual clip displays embedded therein serve to represent individual media parts or channels, or individual attached effects. Due to the recursive nature of Lumiera's HighLevelModel, each of these parts exposes essentially the same controls, allowing to control the respective aspects of the part in question. We may even consider ({{red{unclear as of 11/16}}}) to allow accessing the parts of a VirtualClip, this way turning the enclosing clip into a lightweight container ({{red{11/2016 give proper credit for this concept! Who proposed this initially in 2008? was this Thosten Wilms?}}}
 
 Finally, there can be a situation where it is just not possible to render any of the aforementioned display styles properly, due to size constraints. Especially, this happens when zooming out such as to show a whole sequence or even timeline in overview. We need to come up with a scheme of ''graceful display degradation'' to deal with this situation -- just naively attempting to render any form might easily send our UI thread into a minute long blocking render state, for no good reason. Instead, in such cases display should fall back to a ''degraded form''
 * showing just a placeholder rectangle, when the clip (or any other media element) will cover a temporal span relating to at least 1 pixel width (configurable trigger condition)
@@ -2561,7 +2561,7 @@ A prime consideration regarding this whole clip presentation strategy is the per
 !clip content rendering
 In a typical editing application, the user can expect to get some visual clue regarding the media content of a clip. For example, sound clips can be visualised as waveform, while movie clips might feature a sequence of images taken from the video. Our intention is to ''use our own rendering engine'' to produce these thumbnails. In fact, our engine is perfectly suited for this task: it has precisely the necessary media decoding and rendering abilities, plus it offers an elaborate system of priorities and deadlines, allowing to throttle the load produced by thumbnail generation. In addition to all those qualities, our engine is planned to be complemented by an "intelligent" frame cache, which, given proper parametrisation, ensures the frequently requested thumbnails will be available for quick display. For this approach to work, we need to provide some infrastructure
 * we need to configure and maintain a //preview rendering strategy.//
-* the request for rendering has to be cast "just somewhere" as message, obviously via the UI-Bus
+* the request for rendering has to be cast "just somewhere" as message, possibly via the UI-Bus
 * actually rendered content will likewise arrive asynchronously as message via UI-Bus.
 * we still need to work out how buffer management for this task will be handled; it should be a derivative of typical buffer management for display rendering.
 * the clip widget needs to provide a simple placeholder drawing to mark the respective space in the interface, until the actual preview arrives.
@@ -2873,6 +2873,20 @@ In order to build a sensible plan for our timeline structure, we need to investi
 }}}
+
+
//Management of dockable content panes//
+Within each top level application window, the usable screen real estate can be split and arranged into a number of standard view building blocks. Each of this //panels// follows a specific preconfigured basic layout -- these are hard coded, yet customisable in detail. There is a finite list of such panel types available:
+* the [[timeline display|GuiTimelineView]]
+* the media viewer
+* asset management
+* information box
+
+!Instantiation
+!Placing and addressing of embedded contents
+A specific problem arises insofar other parts of the UI need to create, address and control some UI entities, which at the same time exist as part of a docking panel. This is a problem of crosscutting concerns: UI control and interaction structure should not be mingled with the generic concern to maintain a component as part of a screen layout. Unfortunately, standard UI toolkit sets are designed incredibly naive ways when it comes to interaction design, and the only available alternative is to rely on a framework, which come with a hard-wired philosophy.
+As a result, we're forced to build our UI from components lacking the decision between //ownership and control.//
+
+
special LayerSeparationInterface which serves the main purpose to load the GuiStarterPlugin, thus bringing up the Lumiera GTK UI at application start.
 
@@ -3133,7 +3147,7 @@ Applying a diff changes the structure, that is, the structure of the local model
 Together this means we get a fix up stage after model changes, where the display is re-adjusted to fit the new situation. This works in concert with the [[display manager|TimelineDisplayManager]] representing only those elements as actual widgets, which get a real chance to become visible. This way we can build on the assumption that the actual number of widgets to be managed any time remains so small as to get away with simple linear list processing. It remains to be seen how far this assumption can be pushed -- the problem is that the GTK container components don't support anything beyond such simple linear list processing; there isn't even a call to remove all child widgets of a container in a single pass.
-
+
To a large extent, the Lumiera user interface is built around a //backbone structure,// known as the UI-Bus.
 But there are some dedicated top-level entities, collaborating to maintain a consistent application lifecycle
 ;Application
@@ -3150,6 +3164,7 @@ But there are some dedicated top-level entities, collaborating to maintain a con
 :the InteractionDirector is the root controller and corresponds to the [[root object in session|ModelRootMO]].
 ;Window List
 :organise and maintain the top level workspace windows
+:which involves the interplay with [[docking panels|GuiDockingPanel]]
 ;Notification Façade
 :attachment point for lower layers and anyone in need to "talk to the UI"
 :the GuiNotificationFacade is a LayerSeparationInterface and integrated with Lumiera's interface system
@@ -3476,20 +3491,20 @@ The concept of a //focus goal// has several ramifications: for one it implies th
 To create such a system is an ambitious goal. We can not reach it in a single step, since it entails the formation of a whole intermediary layer, on top of the //usual UI mechanics,// yet below the concrete UI interactions. Especially, we'd need to clarify the meaning of //perspective,// we need to decide on the relation of top level frame, individual view, layout, focus and //current location within the UI.// On a second thought, building such a system implies we'll have to live with an intermediary state of evolution, where parts of the new framework are already in place without interfering with common conventional usage of the interface as-is.
-
+
//the top-level controller within the UI.//
-In Lumiera, the structures of the model within the [[Session]] (the so called HighLevelModel) are mapped onto corresponding [[tangible UI entities|UI-Element]], which serve as a front-end to represent those entities towards the user. Within the model, there is a //conceptual root node// -- which logically corresponds to the session itself. This [[root element in model|ModelRootMO]] links together the actual top-level entities, which are the (multiple) timelines, with the asset management and defaults and rules configuration within the session.
+In Lumiera, the structures of the model within the [[Session]] (the so called HighLevelModel) are mapped onto corresponding [[tangible UI entities|UI-Element]], which serve as a front-end to represent those entities towards the user. Within this model, there is a //conceptual root node// -- which logically corresponds to the session itself. This [[root element in model|ModelRootMO]] links together the actual top-level entities, which are the (multiple) timelines, together with the asset management and defaults and rules configuration within the session.
 
-And the counterpart of this root element within the UI is the {{{InteractionDirector}}}, a top-level controller. As a controller, it responds to actions like opening a specific timeline, entering the asset management section, opening and closing of the session as a whole, and even shutdown of the application as a whole. Beyond that, the Interaction Director is the connection joint to that part of the UI which deals with global interaction state: this relates to questions about "the current element", "the focus", "where we are right now" (in what "location" or "room" within the UI) and also what tangible interface controller we're actually using (mouse, keyboard, graphics pen, hardware controller, touch screen).
+And the counterpart of this root element within the UI is the {{{InteractionDirector}}}, a top-level controller. As a controller, it responds to actions like opening a specific timeline, entering the asset management section, the request for help, and actions like saving, opening and closing of the session as a whole. Beyond that, the Interaction Director is the connection joint to that part of the UI which deals with global interaction state: this topic relates to questions about "the current element", "the focus", "where we are right now" (in what "location" or "room" within the UI) and also what tangible interface controller we're actually using (mouse, keyboard, graphics pen, hardware controller, touch screen).
 
 Why do we need a connection joint between those parts?
-Because issuing any actions on the model within the session -- i.e. any editing operation -- is like forming a sentence: we need to spell out //what we want to do// and we need to spell out the subject and the object of our activity. And any one of these can, and will in fact, be sometimes derived //from the context of the interaction.// Because, given the right context, it is almost clear what you want to do -- you just need to fill in that tiny little bit of information to actually make it happen. In Lumiera we want to build a good UI, which is an UI well suited to this very human way of interacting with one's environment within a given context.
+Because issuing any actions on the model within the session -- i.e. any editing operation -- is like forming a sentence: we need to spell out //what we want to do// and we need to spell out the subject and the object of our activity. And any one of these can, and will in fact, be sometimes derived //from the context of the interaction.// Because, given the right context, it is almost clear what you want to do -- you just need to fill in that tiny little bit of information to actually make it happen. In Lumiera we strive at building a good UI, which is an UI well suited to this very human way of interacting with one's environment within a given context.
 > to understand this, it is best &rarr; to [[look at some examples|CommandInvocationAnalysis]]
 
 !Children
 The InteractionDirector is part of the model, and thus we have to distinguish between model children and other UI components held as children.
 ;model
-:anything related to global structures falls into that category
+:anything related to //core concerns// and session global structures falls into that category
 :* some parts might be related to ''Asset management''
 :* some concerns might touch questions of ''configuration''
 :* and interaction state is closely related to ''persistent UI state''
@@ -3500,6 +3515,8 @@ The InteractionDirector is part of the model, and thus we have to distinguish be
 :* the [[Navigator]] is a special controller to handle moving the SpotLocator
 
 !Collaborations
+* several global actions are exposed here, like opening the session and creating a new timeline.<br/>Such operations are typically bound into menu and action buttons, and in turn invoke [[commands|CommandHandling]] into the Session
+* some further actions involve the interplay with the [[docking panel manager|GuiDockingPanel]], like e.g. instantiating a new [[timeline display|GuiTimelineView]] into a timeline pane.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 72bd8e753..36dabcdce 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -1345,7 +1345,15 @@ - + + + + + + + + + @@ -2636,7 +2644,7 @@ - + @@ -2699,6 +2707,14 @@ + + + + + + + + @@ -2863,7 +2879,7 @@ - + @@ -3319,8 +3335,8 @@ - - + + @@ -3341,8 +3357,8 @@ - - + + @@ -3537,6 +3553,38 @@ + + + + + + +

+ Problem: Zusammenarbeit +

+

+ mit docking panels +

+ + + + + + + + + + + + + + + + + + + + @@ -3733,14 +3781,23 @@ + + + + + + + + + - + - + @@ -3776,7 +3833,8 @@ - + + @@ -5139,7 +5197,77 @@ - + + + + + + + + + + + + + + + + + + + + + +

+ ...um mal was im UI anzeigen zu können +

+ + + + + + + + + + + + + + + + + + + + + +

+ ...wird zwar vom Skript ausgelesen, +

+

+ aber nicht weiterverwendet. +

+

+ Die Icon-Größen ergeben sich aus den Boxes auf 'plate' +

+ + + + + + + + + + + + + + + + + @@ -12001,7 +12129,7 @@ - + @@ -12026,7 +12154,7 @@ - +