diff --git a/src/lib/sub-id.hpp b/src/lib/sub-id.hpp index 472f7d65d..2a6c094d9 100644 --- a/src/lib/sub-id.hpp +++ b/src/lib/sub-id.hpp @@ -23,10 +23,10 @@ /** @file sub-id.hpp ** Extensible symbolic ID type. - ** @todo (9/09) WIP-WIP-WIP just some vague emerging ideas here... + ** @remark this is a design sketch (from 9/2009) an not used anywhere as of 3/2017... ** ** My observation is that, during design, I did run again and again into a specific - ** situation, which I then needed to circumvent due to a lacking primary solution. + ** situation, which I then needed to circumvent in lack of a first class solution. ** Learning from that experiences, I start building this structured ID template. ** - it shall be an \em symbolic identifier, not an artificial ID ** - the basic value set should be limited and statically type safe. @@ -38,6 +38,7 @@ ** ** @todo 1/2016 this idea seems very reasonable, and we should just make it ** robust and usable, along the lines pointed out by that draft + ** - use std::tuple as storage ** - remove the `format-util` dependency (!) ////////////////////////////////TICKET #985 ** - provide a hash implementation for real ** - extend to arbitrary number of sub-dimensions (variadic) diff --git a/src/proc/cmd.hpp b/src/proc/cmd.hpp new file mode 100644 index 000000000..08ab2c31f --- /dev/null +++ b/src/proc/cmd.hpp @@ -0,0 +1,76 @@ +/* + CMD.hpp - Proc Command definition keys + + 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 cmd.hpp + ** Common ID definitions for Proc-Layer commands. + ** This header is included when defining the actual command scripts, but also + ** from all those UI elements to use and invoke the defined Proc-Layer commands. + ** @todo WIP 3/2017 early draft + ** + ** @see command.hpp + ** @see command-def.hpp + ** @see command-accessor.hpp + ** @see TODO_CommandGuiUsage_test + ** + */ + + + +#ifndef PROC_CMD_H +#define PROC_CMD_H + +#include "lib/error.hpp" +#include "proc/control/command.hpp" +//#include "lib/symbol.hpp" +//#include "proc/common.hpp" + +//#include +//#include + + + + +namespace proc { +namespace cmd { + +// using std::string; +// using lib::Symbol; + using control::Command; + //using std::shared_ptr; + + + + /** + * @todo wtf + */ + + + + + /** */ + + + + +}} // namespace proc::cmd +#endif /*PROC_CMD_H*/ diff --git a/src/proc/cmd/session-cmd.cpp b/src/proc/cmd/session-cmd.cpp new file mode 100644 index 000000000..9bb6e5020 --- /dev/null +++ b/src/proc/cmd/session-cmd.cpp @@ -0,0 +1,69 @@ +/* + SessionCmd - actual proc command scripts for session-global actions + + 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 session-cmd.cpp + ** Actual definition of Proc-Layer command scripts for session-global actions. + ** @todo WIP 3/2017 early draft + ** + ** @see cmd.hpp + ** @see command.hpp + ** @see command-def.hpp + ** @see command-accessor.hpp + ** @see TODO_CommandGuiUsage_test + ** + */ + + +#include "proc/cmd.hpp" +#include "proc/control/command-def.hpp" +//#include "lib/symbol.hpp" +//#include "lib/format-string.hpp" + +//#include + +//using std::string; +//using util::cStr; +//using util::_Fmt; + + +namespace proc { +namespace cmd { + namespace error = lumiera::error; + + + namespace { // implementation helper... + }//(End) implementation helper + + + + + /** storage for.... */ + + + + + /** more to come here...*/ + + + +}} // namespace proc::cmd diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 7330f0766..d07d980d6 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -1472,7 +1472,7 @@ Commands are //defined// using a [[fluent API|http://en.wikipedia.org/wiki/Fluen → see CommandUsage -
+
Commands can be identified and accessed //by name// — consequently there needs to be an internal command registry, including a link to the actual implementing function, thus allowing to re-establish the connection between command and implementing functions when de-serialising a persisted command. To create a command, we need to provide the following information
 * operation function actually implementing the command
 * function to [[undo|UndoManager]] the effect of the command
@@ -1498,6 +1498,10 @@ While generally there is //no limitation// on the number and type of parameters,
 | undoOperation| void |(P1,..PN,MEM)|
 | bind| void |(P1,..PN)|
 Usually, parameters should be passed //by value// — with the exception of target object(s), which are typically bound as MObjectRef, causing them to be resolved at commad execution time (late binding).
+
+!Actual command definition scripts
+The actual scripts bound as functors into the aforementioned command definitions are located in translation units in {{{proc/cmd}}}
+These definitions must be written in a way to ensure that just compiling those translation units causes registration of the corresponding command-~IDs
@@ -1524,7 +1528,7 @@ By design, commands are single-serving value objects; executing an operation rep → more details regarding [[command implementation|CommandImpl]]
-
+
Commands are separated in a handle (the {{{control::Command}}}-object), to be used by the client code, and an implementation level, which is managed transparently behind the stages. Client code is assumed to build a CommandDefinition at some point, and from then on to access the command ''by ID'', yielding the command handle.
 Binding of arguments, invocation and UNDO all are accessible through this frontend.
 
@@ -1537,6 +1541,13 @@ To support this handling scheme, some infrastructure is in place:
 ** a closure, implemented through an argument holder
 ** an undo state capturing mechanism, based on a capturing function provided on definition
 * performing the actual execution is delegated to a handling pattern object, accessed by name.
+
+!Definition and usage
+In addition to the technical specification regarding the command, memento and undo functors, some additional conventions are established
+* Command scripts are defined in translation units in {{{proc/cmd}}}
+* these reside in the corresponding namespace, which is typically aliased as {{{cmd}}}
+* both command definition and usage include the common header {{{proc/cmd.hpp}}}
+* the basic command-~IDs defined therein need to be known by the UI elements using them
@@ -2582,7 +2593,7 @@ This contrastive approach attempts to keep knowledge and definition clustered in → GuiCommandCycle
-
+
//the process of issuing a session command from the UI//
 Within the Lumiera UI, we distinguish between core concerns and the //local mechanics of the UI.// The latter is addressed in the usual way, based on a variation of the [[MVC-Pattern|http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]]. The UI toolkit set, here the GTK, affords ample ways to express actions and reactions within this framework, where widgets in the presentation view are wired with the corresponding controllers vice versa (GTK terms these connections as //"signals"//, we rely on {{{libSigC++}}} for implementation).
 A naive approach would extend these mature mechanisms to also cover the actual functionality of the application. This compelling solution allows quickly to get "something tangible" up and running, yet -- on the long run -- inevitably leads to core concerns being tangled into the presentation layer, which in turn becomes hard to maintain and loaded with "code behind". Since we are here "for the long run", we immediately draw the distinction between UI mechanics and core concerns. The latter are, by decree and axiom, required to perform without even an UI layer running. This decision gives rise to the challenge how to form and integrate the invocation of ''core commands'' into the presentation layer.
@@ -2624,7 +2635,13 @@ from these use cases, we can derive the //crucial activities for command handlin
 [<img[Access to Session Commands from UI|uml/Command-ui-access.png]]
 An immediate consequence is that command instances will be formed //per instance// of InteractionStateManager. Each distinct kind of control system has its own instances, which are kept around, until they are ready for invocation. Each invocation "burns" an instance -- on next access, a new instance ID will be allocated, and the next command invocation cycle starts...
 
-Command instances are like prototypes -- thus each additional level of differentiation will create a clone copy and decorate the basic command ID. Yet this extension process is delegated into multiple stages. Already when a specific InvocationTrail is established, the bare command prototype is specialised, and additionally combined with specific context access rules and maybe even a accessor to retrieve some argument value. The {{{CmdInstanceManager}}} internally maintains and tracks a prepared command instance, supplying a distinct instance number to keep concurrently existing instances apart; instances might be around for an extended period, because commands are enqueued with the ProcDispatcher.
+Command instances are like prototypes -- thus each additional level of differentiation will create a clone copy and decorate the basic command ID. Yet this extension process is delegated into multiple stages. Already when a specific InvocationTrail is established, the bare command prototype is specialised, and additionally combined with specific context access rules and maybe even a accessor to retrieve some argument value. The {{{CmdInstanceManager}}} internally maintains and tracks a prepared command instance, supplying a distinct instance number to keep concurrently existing instances apart; instances might be around for an extended period, because commands are enqueued with the ProcDispatcher. + +''command definition'': +&rarr; Command scripts are defined in translation units in {{{proc/cmd}}} +&rarr; They reside in the corresponding namespace, which is typically aliased as {{{cmd}}} +&rarr; definitions and usage include the common header {{{proc/cmd.hpp}}} + 
All communication between Proc-Layer and GUI has to be routed through the respective LayerSeparationInterfaces. Following a fundamental design decision within Lumiera, these interface are //intended to be language agnostic// &mdash; forcing them to stick to the least common denominator. Which creates the additional problem of how to create a smooth integration without forcing the architecture into functional decomposition style. To solve this problem, we rely on ''messaging'' rather than on a //business facade// -- our facade interfaces are rather narrow and limited to lifecycle management. In addition, the UI exposes a [[notification facade|GuiNotificationFacade]] for pushing back status information created as result of the edit operations, the build process and the render tasks.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index edb6efb81..a51b3b0ff 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -605,8 +605,7 @@
       des Gui-top-Level nach sich
     

   
-
-
+
 
 
 
@@ -2078,54 +2077,13 @@
       und den Teufelskreis zu durchbrechen!
     

   
-
-
+
 
 
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
 
 
 
@@ -2167,8 +2125,7 @@
       (Beispiel "in-point fehlt")
     

   
-
-
+
 
 
 
@@ -2186,97 +2143,7 @@
       aber von einem externen State-Change getriggert wird
     

   
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-    
-  
-  
-    

-      die Idee ist hier,
-    

-    

-      daß diese generischen Rollen bereits in der Einrichtung der Command-Definition verwendet werden.
-    

-    

-      Das heißt, für einen bestimmten Invocation-Trail legt man fest,
-    

-    

-      daß ein bestimmtes Argument an eine gewisse Rolle gebunden wird,
-    

-    

-      oder andernfalls einen bestimmten Namen bekommt
-    

-  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
 
 
 
@@ -2296,8 +2163,7 @@
       da es nur darum geht, via globalCtx auf den passenden Controller zuzugreifen
     

   
-
-
+
 
 
 
@@ -2426,12 +2292,27 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
-
-
 
 
+
+
 
 
 
@@ -11262,8 +11143,7 @@
       mehrere Commands zuständig sein
     

   
-
-
+
 
 
 
@@ -11280,8 +11160,7 @@
       ein Command zuständig sein
     

   
-
-
+
 
 
 
@@ -11299,8 +11178,7 @@
       und ebenso die Gesten abstrahieren
     

   
-
-
+
 
 
 
@@ -11326,8 +11204,7 @@
       muß Instanzen einsetzen
     

   
-
-
+
 
   
     
@@ -11345,8 +11222,7 @@
       
     
   
-
-
+
 
 
 
@@ -11380,8 +11256,7 @@
       sondern gegen eine Abstraction (Command), die eigens dafür geschaffen wurde
     

   
-
-
+
 
 
 
@@ -11456,8 +11331,7 @@
       
     
   
-
-
+
 
 
 
@@ -11473,8 +11347,7 @@
       ...da die DispatcherQueue direkt Command-Objekte (=frontend handle) speichert
     

   
-
-
+
 
 
 
@@ -11502,8 +11375,7 @@
       und wenn es stirbt, dann stirbt es halt...
     

   
-
-
+
 
 
 
@@ -11541,8 +11413,7 @@
       GUI: CmdAccessor
     

   
-
-
+
 
 
 
@@ -11556,8 +11427,7 @@
       Proc: CmdInstanceManager
     

   
-
-
+
 
 
 
@@ -11599,8 +11469,7 @@
       mit dem InteractionDirector verdrahtet sein muß!
     

   
-
-
+
 
 
 
@@ -11617,8 +11486,7 @@
       und auch nichts mit der Trennung zwischen Layern und Subsystemen
     

   
-
-
+
 
 
 
@@ -11633,8 +11501,7 @@
       aka DependencyInjection + Lifecycle Management
     

   
-
-
+
 
 
 
@@ -11659,8 +11526,7 @@
       
     
   
-
-
+
 
 
 
@@ -11682,8 +11548,7 @@
       es könnte auch ausreichen, einfach die passende InteractionStateManager-Impl zu verwenden
     

   
-
-
+
 
 
 
@@ -11696,8 +11561,7 @@
       denn InteractionStateManager ist ein Interface!
     

   
-
-
+
 
 
 
@@ -11720,8 +11584,7 @@
       Das könnte ein Advice sein
     

   
-
-
+
 
 
 
@@ -11742,8 +11605,7 @@
       In diesem Fall wird das Command enabled
     

   
-
-
+
 
 
 
@@ -11755,8 +11617,7 @@
       eine Argumentliste mit mehreren Parametern wir Schritt für Schritt geschlossen
     

   
-
-
+
 
 
 
@@ -11771,8 +11632,7 @@
       wird das gemäß Scope "nächstgelegne" genommen
     

   
-
-
+
 
 
 
@@ -11803,7 +11663,7 @@
 
 
 
-
+
 
 
 
@@ -11832,6 +11692,207 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      ...stattdessen einen Fehler-Indikator auslösen
+    

+    

+      (Beispiel "in-point fehlt")
+    

+  
+
+
+
+
+  
+    
+  
+  
+    

+      ...das ist eine Reaktion,
+    

+    

+      die von einem managing Ui-Element ausgeführt wird,
+    

+    

+      aber von einem externen State-Change getriggert wird
+    

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

+      die Idee ist hier,
+    

+    

+      daß diese generischen Rollen bereits in der Einrichtung der Command-Definition verwendet werden.
+    

+    

+      Das heißt, für einen bestimmten Invocation-Trail legt man fest,
+    

+    

+      daß ein bestimmtes Argument an eine gewisse Rolle gebunden wird,
+    

+    

+      oder andernfalls einen bestimmten Namen bekommt
+    

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