From cddc5afe415777dbce94c75c3596b7db5c162b8c Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 19 Feb 2017 02:50:55 +0100 Subject: [PATCH] UI-top-level: establish top-level model and control structure --- src/gui/ctrl/global-ctx.hpp | 4 +- src/gui/interact/interaction-director.hpp | 28 +++++- src/gui/setting/asset-controller.cpp | 62 +++++++++++++ src/gui/setting/asset-controller.hpp | 91 +++++++++++++++++++ wiki/renderengine.html | 9 +- wiki/thinkPad.ichthyo.mm | 101 ++++++++++++++++++++-- 6 files changed, 279 insertions(+), 16 deletions(-) create mode 100644 src/gui/setting/asset-controller.cpp create mode 100644 src/gui/setting/asset-controller.hpp diff --git a/src/gui/ctrl/global-ctx.hpp b/src/gui/ctrl/global-ctx.hpp index 11609163e..310ebab84 100644 --- a/src/gui/ctrl/global-ctx.hpp +++ b/src/gui/ctrl/global-ctx.hpp @@ -87,8 +87,8 @@ namespace ctrl { UiBus& uiBus_; UiManager& uiManager_; - InteractionDirector director_; WindowList windowList_; + InteractionDirector director_; public: @@ -98,8 +98,8 @@ namespace ctrl { GlobalCtx (UiBus& bus, UiManager& manager) : uiBus_{bus} , uiManager_{manager} - , director_{*this} , windowList_{*this} + , director_{*this} { } private: diff --git a/src/gui/interact/interaction-director.hpp b/src/gui/interact/interaction-director.hpp index be05feb03..c4e258e3d 100644 --- a/src/gui/interact/interaction-director.hpp +++ b/src/gui/interact/interaction-director.hpp @@ -59,6 +59,7 @@ //#include //#include //#include +#include #include @@ -68,13 +69,23 @@ namespace gui { namespace ctrl { class GlobalCtx; + class UiState; +} +namespace setting { + class AssetController; +} +namespace timleine { + class TimelineController; } namespace interact { //using std::string; + using std::unique_ptr; //class Actions; -//class WindowList; + class SpotLocator; + class Navigator; + class FocusTracker; @@ -85,10 +96,21 @@ namespace interact { class InteractionDirector : public model::Controller { - ctrl::GlobalCtx& globalCtx_; - ////TODO: what is the model equivalent represented here??? + // == global Services == + unique_ptr spotLocator_; + unique_ptr navigator_; + unique_ptr tracker_; + + // == Model globals == + using Timelines = std::vector>; + using Assets = unique_ptr; + using State = unique_ptr; + + State uiState_; + Assets assets_; + Timelines timelines_; /** set up a binding to allow some top-level UI state * to be treated as part of the session model diff --git a/src/gui/setting/asset-controller.cpp b/src/gui/setting/asset-controller.cpp new file mode 100644 index 000000000..cb84bfab2 --- /dev/null +++ b/src/gui/setting/asset-controller.cpp @@ -0,0 +1,62 @@ +/* + AssetController - asset management UI top level + + 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 asset-controller.cpp + ** Implementation of the asset management UI top level. + ** + ** @todo WIP 2/2017 early draft / foundations of "interaction control" + ** + */ + + +//#include "gui/gtk-lumiera.hpp" +#include "gui/setting/asset-controller.hpp" +//#include "gui/ctrl/global-ctx.hpp" +//#include "lib/util.hpp" + +//using util::cStr; +//using util::isnil; + + +namespace gui { +namespace setting { + + + + // dtors via smart-ptr invoked from here... + AssetController::~AssetController() + { } + + + /** + * Define a new coherent location within _"interface space"_ for future interaction. + */ + AssetController::AssetController() + { } + + + /** */ + + + +}}// namespace gui::setting diff --git a/src/gui/setting/asset-controller.hpp b/src/gui/setting/asset-controller.hpp new file mode 100644 index 000000000..f88c710d4 --- /dev/null +++ b/src/gui/setting/asset-controller.hpp @@ -0,0 +1,91 @@ +/* + ASSET-CONTROLLER.hpp - asset management UI top level + + 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 asset-controller.hpp + ** User interface for asset management. + ** Aside of the media objects to be edited, the session holds a section dedicated + ** to the bookkeeping aspects, where all of the assets relevant to the project are + ** listed, catalogued and tracked. There is a corresponding section in the UI to + ** offer this bookkeeping view -- which includes the tremendously important hierarchy + ** of media and clip bins, where all of the material is organised and prepared for + ** editing. Another topic subsumed under _asset management,_ yet presented separately + ** is anything related to settings and project setup. + ** + ** As with any part of the UI, there is some correspondence to session model components + ** and a connection via UI-Bus and diff framework. We get one top-level UI element, the + ** AssetController, to correspond to the asset::AssetManager in the session. The + ** basically fixed structure of asset categories and subsections is reflected in + ** likewise fixed access operations in this controller, allowing to enter a + ** dedicated UI for each of the asset subsections... + ** + ** @todo WIP 2/2017 early draft / a new UI backbone + ** + ** @see proc::mobject::Session + ** @see proc::asset::Asset + ** @see timeline-controller.hpp + ** @see interaction-director.hpp + ** @see ui-bus.hpp + */ + + +#ifndef GUI_SETTING_ASSET_CONTROLLER_H +#define GUI_SETTING_ASSET_CONTROLLER_H + +#include "gui/gtk-base.hpp" + +#include +//#include +//#include + + +namespace gui { +namespace setting { + +// using std::unique_ptr; +// using std::string; + +// class GlobalCtx; + + + + /** + * Top level controller for the asset managment section in the UI. + * + * @todo initial draft as of 2/2017 -- actual implementation has to be filled in + */ + class AssetController + : boost::noncopyable + { + + public: + AssetController(); + ~AssetController(); + + private: + + }; + + + +}}// namespace gui::setting +#endif /*GUI_SETTING_ASSET_CONTROLLER_H*/ diff --git a/wiki/renderengine.html b/wiki/renderengine.html index f566bb434..a88f81eb7 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2717,7 +2717,7 @@ More specifically, the integration is based on ''messaging''. To start with, the ---- In a preliminary attempt to establish an integration between the GUI and the lower layers, in 1/2009 we created an PlayerDummy, which "pulls" dummy frames from the (not yet existing) engine and displays them within an XV viewer widget. This highlighted the problems we're about to encounter and made us think about the more radically decoupled approach we followed thereafter... -
+
Building a layered architecture is a challenge, since the lower layer //really// needs to be self-contained, while prepared for usage by the higher layer.
 A major fraction of all desktop applications is written in a way where operational logic is built around the invocation from UI events -- what should be a shell turns into a backbone. One possible way to escape from this common anti pattern is to introduce a mediating entity, to translate between two partially incompatible demands and concerns: Sure, the "tangible stuff" is what matters, but you can not build any significant piece of technology if all you want is to "serve" the user.
 
@@ -2727,6 +2727,9 @@ The GUI model is largely comprised of immutable ID elements, which can be treate
 → [[Building blocks of the GUI model|GuiModelElements]]
 → [[GUI update mechanics|GuiModelUpdate]]
 
+!{{red{WARNING 2/2017}}} more questionable than ever
+The whole Idea to have a "UI model" appears more questionable than ever. It leads to tight coupling with the session and a lot of thread synchronisation headaches, without any clear benefit -- beyond just being the obvious no-brainer solution. During the last months, step by step, several presentation related structures emerged, which //indeed are structured to parallel the outline of the session.// But those structures are widgets and controllers, and it might well be that we do not need a model, beyond the data already present within the widget implementation. Rather it seems we'll get a nested structure of //presenters,// which are linked to the session with the help of the UI-Bus and the [[diff framework|TreeDiffModel]].
+
 !synchronisation guarantees
 We acknowledge that the gui model is typically used from within the GUI event dispatch thread. This is //not// the thread where any session state is mutated. Thus it is the responsibility of this proxying model within the GUI to ensure that the retrieved structure is a coherent snapshot of the session state. Especially the {{{gui::model::SessionFacade}}} ensures that there was a read barrier between the state retrieval and any preceding mutation command. Actually, this is implemented down in Proc-Layer, with the help of the ProcDispatcher.
 
@@ -9191,7 +9194,7 @@ The UI-Bus has a star shaped topology, with a central "bus master" hub
 :direct a MutationMessage towards the designated UI-Element, causing the latter to build a TreeMutator to receive the embedded [[diff-sequence|TreeDiffModel]]
-
+
While our UI widgets are implemented the standard way as proposed by [[GTKmm|http://www.gtkmm.org/en/documentation.html]], some key elements -- which are especially relevant for the anatomy and mechanics of the interface at a whole -- are made to conform to a common interface and behaviour protocol. {{red{WIP 11/15 work out gradually what this protocol is all about}}}. #975
 As a starting point, we know
 * there is a backbone structure known as the UI-Bus
@@ -9262,7 +9265,7 @@ A command's {{{InvocationTrail}}} is in fact just some tag object, wrapping the
 It is clear by now (9/2016) how shape and content changes are to be represented as diff message. Moreover, we have an implementation framework to build the concrete TreeMutator, which allows to target diff messages towards a (otherwise undisclosed) opaque implementation data structure.
 !!!questions
 * how to integrate "diff calls" into UI-Bus and {{{Tangible}}}
-* how to ensure, diff processing happens within the event thread
+* how to ensure that diff processing happens within the event thread
 * what is the exact relation to the GuiModel -- this remained nebulous up to now
 
 !!!Diff messages
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 886c24059..d217fbca9 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -33,7 +33,8 @@
 
 
 
-
+
+
 
 
 
@@ -1744,7 +1745,7 @@
 
 
 
-
+
 
 
 
@@ -2091,7 +2092,7 @@
 
 
 
-
+
 
 
 
@@ -2110,7 +2111,6 @@
 
 
 
-
 
 
 
@@ -2131,8 +2131,7 @@
       müssen wir sofort jetzt implementieren
     

   
-
-
+
 
 
 
@@ -2144,8 +2143,7 @@
       brauche ein aktuelles Modell-Element
     

   
-
-
+
 
 
 
@@ -2200,6 +2198,31 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -2653,6 +2676,60 @@
 
 
 
+
+
+  
+    
+  
+  
+    

+      Problem: Slave-Timeline
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -3774,6 +3851,14 @@
 
 
 
+
+
+
+
+
+
+
+