Global-Layer-Renaming: adjust namespace qualification

doc/design/application/SubsystemLifecycle.txt

@@ -48,7 +48,7 @@ for the code referred in the following discussion.
   additionally the services of +lumiera::AppState+ (+common/appstate.hpp+)
 - AppState represents the state as relevant for the "application realm", i.e.
   it performs global initialisation and shutdown. See especially +AppState::init()+
-- see +backend/enginefacade.hpp|cpp+ as an (unimplemented) façade skeleton. +backend::EngineFacade::getDescriptor()+
+- see +vault/enginefacade.hpp|cpp+ as an (unimplemented) façade skeleton. +vault::EngineFacade::getDescriptor()+
   yields the subsystem interface
 - the GuiFacade is somewhat special, because we want to load the GUI from a
   shared library. This façade is basically completed and working, but it currently
@@ -61,7 +61,7 @@ for the code referred in the following discussion.
   separation interfaces are considered part of the public Lumiera API, thus the
   headers go into +src/include/**+
   * include/guinotification.h (C/C++ combined header) defines an C++ interface (abstract class) and a CLI interface. 
-  * embedded into the interface is a factory, i.e. by  gui::GuiNotification::facade() you get an instance...
+  * embedded into the interface is a factory, i.e. by  stage::GuiNotification::facade() you get an instance...
   * which actually is a proxy and routes any call through the instance of the
     accompanying CLI interface which is defined within the interface/plugin system
   * this in turn forwards to the implementation class in

doc/technical/code/gtk/index.txt

@@ -72,7 +72,7 @@ tend to get into our way of working. For this reason
 Consequently, none of the services offered by `Gtk::Application` is of much use for us. After reading
 the source code, we came to the conclusion that it is perfectly valid to sidestep all those aspects
 of GTK, and just perform those small number of toolkit initialisation steps -- previously invoked
-by `Gtk::Main` -- directly from our application code. Basically Lumiera's `gui::ctrl::UiManager`
+by `Gtk::Main` -- directly from our application code. Basically Lumiera's `stage::ctrl::UiManager`
 replaces `Gtk::Main`, invokes `gtk_init` and enters the blocking event loop by calling `gtk_main`.
 
 

doc/technical/code/gtk/startup.txt

@@ -53,15 +53,15 @@ to the plain-C type `GApplication`.] Thus, we leave out the third stage and deal
 application global aspects through means appropriate to our specific purpose.
 
 - our link:{ldoc}/design/architecture/Subsystems.html[Subsystem runner] boots the UI subsystem
-  (`gui::GuiFacade`), which in turn loads the UI-plug-in ('target/modules/gtk_gui.lum').
-- within this plug-in, the class `gui::GtkLumiera` governs the complete UI lifecycle.
-- this class holds a member `gui::ctl::UiManager` -- which is our ``UI main object'' and mimics
+  (`stage::GuiFacade`), which in turn loads the UI-plug-in ('target/modules/gtk_gui.lum').
+- within this plug-in, the class `stage::GtkLumiera` governs the complete UI lifecycle.
+- this class holds a member `stage::ctl::UiManager` -- which is our ``UI main object'' and mimics
   the design of the late `Gtk::Main`.
-- we inherit from our own `gui::ctrl::ApplicationBase` class, to ensure invocation of all the
+- we inherit from our own `stage::ctrl::ApplicationBase` class, to ensure invocation of all the
   initialisation and clean-up functions required by GTK
-- we instantiate a class `gui::ctrl::GlobalCtx` to hold and provide all global services used
+- we instantiate a class `stage::ctrl::GlobalCtx` to hold and provide all global services used
   throughout the UI layer, including population of the menu and global actions
-- within the global context, there is also `gui::ctrl::WindowLocator`, to keep track of all
+- within the global context, there is also `stage::ctrl::WindowLocator`, to keep track of all
   top-level application windows, and to support direct navigation to relevant entities within
   the UI, based on _abstracted UI-coordinates_.
 - finally, `GtkLumiera` invokes the functions
@@ -138,7 +138,7 @@ Shutdown
 --------
 The GTK main loop terminates after invocation of `gtk_main_quit()` (or in case of serious internal errors).
 Typically, this function is somehow bound to a widget interaction, like clicking on the ``close'' button.
-In Lumiera, this concern is managed by the `gui::ctrl::WindowLocator`, which keeps track of all top-level
+In Lumiera, this concern is managed by the `stage::ctrl::WindowLocator`, which keeps track of all top-level
 windows and terminates the UI when the last one is closed. Moreover, the UI can deliberately be closed
 by sending an event over the `GuiNotification::triggerGuiShutdown(message)' call.
 

doc/technical/stage/CodePolicy.txt

@@ -30,7 +30,7 @@ UI-Model
 In short: _there is no dedicated UI-Model._ Stateful working data goes directly
 into the widgets. However, some widgets or controllers are special, insofar they
 correspond to and reflect some entities within the _Session model._ These special
-entities must be implemented as subclasses of `gui::model::Tangible`. These are
+entities must be implemented as subclasses of `stage::model::Tangible`. These are
 always connected to the UI-Bus, and they are populated and mutated by receiving
 diff messages pushed up from the Steam-Layer.
 

doc/technical/stage/GuiConnect.txt

@@ -63,7 +63,7 @@ dispatches any invocation into the UI thread.
 
 Within the UI-Layer, we do not rely on a central ``shadow model'', rather, the backbone of the UI is a communication
 structure, the *UI-Bus*. Data within the GUI is kept very local, close to the presentation widgets. In fact, we
-identify a selection of _really important_ UI elements, which we call ``the tangible elements'' (`gui::model::Tangible`).
+identify a selection of _really important_ UI elements, which we call ``the tangible elements'' (`stage::model::Tangible`).
 Each of those primary elements within the UI _is connected to the UI-Bus,_ and can be addressed by its ID, and it
 happens to correspond and reflect an entity within the session model, there denoted by the same ID. The core can
 thus send a message towards the corresponding tangible UI element, without any knowledge as to how and where this

research/gtk-canvas-main.cpp

@@ -25,7 +25,7 @@
  ** This demo application was extracted in 10/2018 to preserve
  ** [exploration experiments](\ref demo::CanvasDemoPanel), carried
  ** out in 2016 to decide upon the technology to support Lumiera's
- ** gui::timeline::TimelineWidget.
+ ** stage::timeline::TimelineWidget.
  */
 
 

src/common/display-interface-proxy.cpp

@@ -54,7 +54,7 @@ namespace facade {
   
   
   
-  /* ==================== gui::Display ====================================== */
+  /* ==================== stage::Display ====================================== */
   
   using Interface = LUMIERA_INTERFACE_INAME(lumieraorg_Display, 0);
   using Facade    = lumiera::Display;

src/common/guifacade.cpp

@@ -25,7 +25,7 @@
  ** Implementation of the GUI loader. Code generated from this
  ** translation unit is linked into the core application, where it implements
  ** the [Subsystem descriptor](\ref subsys.hpp) for the _UI Subsystem._ When main()
- ** activates and starts this subsystem, an instance of gui::GuiRunner will be
+ ** activates and starts this subsystem, an instance of stage::GuiRunner will be
  ** created, which causes the Lumiera UI plug-in to be loaded and a new thread
  ** to be spawned, which launches the UI and performs the event loop.
  */

src/common/instancehandle.hpp

@@ -29,7 +29,7 @@
  ** out of scope. Additionally, access via an (existing) interface proxy
  ** may be enabled and disabled alongside with the loading and unloading.
  **
- ** @see gui::GuiFacade usage example
+ ** @see stage::GuiFacade usage example
  ** @see interface.h
  ** @see interfaceproxy.hpp (more explanations)
  ** @see session-command-interface-proxy.cpp (Proxy implementation example)

src/common/notification-interface-proxy.cpp

@@ -23,8 +23,8 @@
 
 
 /** @file notification-interface-proxy.cpp
- ** Interface-Proxy for the gui::GuiNotification facade.
- ** The purpose is to define a proxy implementation of gui::GuiNotification, in order to
+ ** Interface-Proxy for the stage::GuiNotification facade.
+ ** The purpose is to define a proxy implementation of stage::GuiNotification, in order to
  ** redirect any calls through the associated C Language Interface "lumieraorg_GuiNotification"
  ** 
  ** @see gui-notification-facade.hpp
@@ -41,7 +41,7 @@ namespace stage {
 }
 namespace lumiera {
 namespace facade {
-  using gui::ID;
+  using stage::ID;
   using lib::diff::GenNode;
   using lib::diff::MutationMessage;
   
@@ -50,7 +50,7 @@ namespace facade {
   /* ==================== SessionCommand =================================== */
   
   using Interface = LUMIERA_INTERFACE_INAME(lumieraorg_GuiNotification, 0);
-  using Facade    = gui::GuiNotification;
+  using Facade    = stage::GuiNotification;
   
   using IHandle   = InstanceHandle<Interface, Facade>;
   
@@ -59,7 +59,7 @@ namespace facade {
   class Proxy<IHandle>
     : public Binding<IHandle>
     {
-      using Level = gui::NotifyLevel;
+      using Level = stage::NotifyLevel;
       
       //----Proxy-Implementation-of-GuiNotification--------
       

src/common/query/defs-manager-impl.hpp

@@ -32,7 +32,7 @@
  ** core MObject types, alongside with the definition of the generic config-query-resolver.
  ** 
  ** @see config-resolver.cpp definition of the explicit specialisations for the session 
- ** @see proc::ConfigResolver
+ ** @see steam::ConfigResolver
  **
  */
 
@@ -51,7 +51,7 @@
 
 using util::_Fmt;
 
-using proc::ConfigResolver;
+using steam::ConfigResolver;
 using lumiera::query::QueryHandler;                    ///////TODO preliminary interface defined in config-rules.hpp
 using lumiera::query::LERR_(CAPABILITY_QUERY);
 

src/include/display-facade.h

@@ -34,7 +34,7 @@
  **  registers with the OutputManager in the core.
  ** 
  ** @see [corresponding implementation](\ref display-service.hpp)
- ** @see gui::GuiFacade
+ ** @see stage::GuiFacade
  ** @see dummy-player-facade.h
  ** 
  */
@@ -80,7 +80,7 @@ namespace lumiera {
    *       considerably if we get at devising the real player.
    * 
    * @see dummy-player-facade.hpp
-   * @see gui::PlaybackController 
+   * @see stage::PlaybackController 
    * 
    */
   class Display

src/include/display-handles.h

@@ -24,7 +24,7 @@
  ** Opaque handles and similar typedefs used to communicate via the
  ** lumiera::Display and lumiera::DummyPlayer facade interfaces.
  **
- ** @see gui::DisplayService
+ ** @see stage::DisplayService
  ** 
  */
 

src/include/gui-notification-facade.h

@@ -31,7 +31,7 @@
  ** to happen in the UI in response to the reception of these messages.
  **
  ** @see notification-service.hpp implementation
- ** @see gui::GuiFacade
+ ** @see stage::GuiFacade
  ** @see main.cpp
  */
 

src/include/play-facade.hpp

@@ -105,7 +105,7 @@ namespace lumiera {
          * @see player-service.cpp implementation
          */
         class Controller
-          : public lib::Handle<proc::play::PlayProcess>
+          : public lib::Handle<steam::play::PlayProcess>
           {
           public:
             void play(bool);          ///< play/pause toggle
@@ -126,17 +126,17 @@ namespace lumiera {
             uint getQuality()   const;
             bool usesProxy()    const;
             
-            operator weak_ptr<proc::play::PlayProcess>()  const;
+            operator weak_ptr<steam::play::PlayProcess>()  const;
           };
         
         
-        using ModelPorts = lib::IterSource<proc::mobject::ModelPort>::iterator;
-        using Pipes      = lib::IterSource<proc::mobject::OutputDesignation>::iterator;
-        using Output     = proc::play::POutputManager;
-        using Clip       = proc::mobject::session::PClip;
-        using Fork       = proc::mobject::PFork;
-        using Timeline   = proc::asset::PTimeline;
-        using Viewer     = proc::asset::PViewer;
+        using ModelPorts = lib::IterSource<steam::mobject::ModelPort>::iterator;
+        using Pipes      = lib::IterSource<steam::mobject::OutputDesignation>::iterator;
+        using Output     = steam::play::POutputManager;
+        using Clip       = steam::mobject::session::PClip;
+        using Fork       = steam::mobject::PFork;
+        using Timeline   = steam::asset::PTimeline;
+        using Viewer     = steam::asset::PViewer;
         
         
         /* ==== convenience shortcuts for common use cases ==== */

src/include/session-command-facade.h

@@ -33,14 +33,14 @@
  ** accept the command arguments for binding packaged as `Record<GenNode>`.
  ** For each command, there needs to be a registration record within the
  ** Steam-Layer implementation. The service implementation backing this
- ** facade indeed retrieves the corresponding proc::control::Command
+ ** facade indeed retrieves the corresponding steam::control::Command
  ** handles to perform the binding operation and hands them over
  ** to the ProcDispatcher for invocation.
  ** 
  ** @see command.hpp
  ** @see session-command-service.hpp implementation
- ** @see proc::control::ProcDispatcher
- ** @see gui::ctrl::CoreService
+ ** @see steam::control::ProcDispatcher
+ ** @see stage::ctrl::CoreService
  */
 
 
@@ -68,7 +68,7 @@ namespace control {
   /**********************************************************************//**
    * Global access point to invoke commands and cause edit operations within
    * the Session. Any changes to the session are effected by prepared functors
-   * bound into a proc::control::Command registration. A command instance will
+   * bound into a steam::control::Command registration. A command instance will
    * first be outfitted with suitable parameters to define the target and to
    * qualify and elaborate the action, before it can be actually triggered.
    * Commands then go through a queue to be invoked one by one.

src/include/ui-protocol.hpp

@@ -27,7 +27,7 @@
  ** running an asynchronous communication protocol.
  ** - the [UI-Bus](\ref ui-bus.hpp) allows for some specific kinds of messages to be
  **   sent either "upstream" (towards the CoreService) or "downstream" to individual
- **   [UI-Elements](\ref gui::model::Tangible) known by ID.
+ **   [UI-Elements](\ref stage::model::Tangible) known by ID.
  ** - these ["tangible interface elements"](\ref tangible.hpp) themselves define a
  **   basic set of actions and "state mark" messages, known as the "element protocol"
  ** - and changes to the structure of tangible elements exposed through the UI are

src/lib/call-queue.hpp

@@ -29,7 +29,7 @@
  **       based on std::function; should use a lock-fee queue and should have an eye
  **       on the impact of managing argument storage
  ** 
- ** @see gui::NotificationService usage example
+ ** @see stage::NotificationService usage example
  */
 
 

src/lib/diff/mutation-message.hpp

@@ -40,7 +40,7 @@
  ** and transported through the message -- since a diff sequence as such is always concrete and relates to a
  ** a specific context, we can not represent it directly as a type on interface level. Rather, the receiver
  ** of a diff sequence must offer the ability to be reshaped through diff messages, which is expressed through
- ** the interface DiffMutable. In the case at question here, gui::model::Tangible offers this interface and thus
+ ** the interface DiffMutable. In the case at question here, stage::model::Tangible offers this interface and thus
  ** the ability to construct a concrete lib::diff::TreeMutator, which in turn is bound to the internals of the
  ** actual UI-Element. In this framework, a diff is actually represented as a sequence of _diff verbs,_ which
  ** can be ``pulled'' one by one from the MutationMessage, and then applied to the target data structure

src/lib/format-obj.cpp

@@ -199,9 +199,9 @@ apologies for that."
                                 "|lib::diff::"
                                 "|lib::"
                                 "|util::"
-                                "|proc::(asset::|mobject::(session::)?|play::)?"
-                                "|gui::model"
-                                "|gui::ctrl"
+                                "|steam::(asset::|mobject::(session::)?|play::)?"
+                                "|stage::model"
+                                "|stage::ctrl"
                                 "|lumiera::"
                                 , regex::ECMAScript | regex::optimize};
     

src/lib/handle.hpp

@@ -35,7 +35,7 @@
  ** of the implementation class the handle points at is necessary only in the
  ** translation unit implementing such an extended handle.
  **
- ** @see proc::control::Command usage example
+ ** @see steam::control::Command usage example
  ** 
  */
 

src/lib/idi/entry-id.hpp

@@ -35,7 +35,7 @@
  ** @todo as of 11/2018 the basic design seems adequate, but the actual solution looks fishy.
  **       Even more so, since we now use subclasses of BareEntryID
  **       - as identity tag within lib::diff::GenNode
- **       - as identity tag for all [tangible UI elements](\ref gui::model::Tangible)
+ **       - as identity tag for all [tangible UI elements](\ref stage::model::Tangible)
  **       There are various quirks and hacks to make all of this happen, and especially
  **       the hashed-in type information feels gratuitous at places, when all we actually
  **       need is a distinct identity plus a human readable symbol.

src/lib/iter-explorer.hpp

@@ -62,7 +62,7 @@
  ** - the more low-level RecursiveSelfIntegration combinator strategy actually
  **   delegates to the result set iterator implementation to perform the collecting
  **   and re-integrating of intermediary results. This approach is what we actually
- **   use in the proc::engine::Dispatcher
+ **   use in the steam::engine::Dispatcher
  ** 
  ** Alternatively, just the basic IterExplorer template can be used together with a custom
  ** "combinator strategy" and typically even a specific iterator or sequence to implement very specific

src/lib/maybe.hpp

@@ -41,7 +41,7 @@
  ** @todo WIP and rather brainstorming as of 2/10
  ** @deprecated as of 2016 : the upcoming C++17 will provide an optional type!!
  ** 
- ** @see backend::ThreadJob usage example
+ ** @see vault::ThreadJob usage example
  */
 
 

src/lib/meta/configflags.hpp

@@ -38,8 +38,8 @@
  ** which would lead to more and more code bloat with growing number of possible
  ** combinations.
  ** 
- ** @see proc::engine::config::Strategy usage example
- ** @see proc::engine::config::ConfigSelector 
+ ** @see steam::engine::config::Strategy usage example
+ ** @see steam::engine::config::ConfigSelector 
  ** @see typelist.hpp
  ** 
  */

src/lib/path-array.hpp

@@ -40,7 +40,7 @@
  ** 
  ** @see PathArray_test
  ** @see UICoord_test
- ** @see gui::interact::UICoord
+ ** @see stage::interact::UICoord
  ** @see view-spec-dsl.hpp
  */
 

src/lib/priqueue.h

@@ -35,7 +35,7 @@
  **       any but the topmost element. The idea is to let expired elements sink to the top
  **       and just detect and remove them on next access.
  ** 
- ** @see backend::engine::SchedulerFrontend
+ ** @see vault::engine::SchedulerFrontend
  ** 
  */
 

src/lib/replaceable-item.hpp

@@ -50,7 +50,7 @@
  **    by providing an explicit specialisation of lib::NullValue for this type.
  ** 
  ** @see ReplaceableIterm_test
- ** @see proc::control::MementoTie
+ ** @see steam::control::MementoTie
  ** 
  */
 

src/lib/result.hpp

@@ -30,7 +30,7 @@
  ** valid or failure state, which can be tested. Any attempt to get the value
  ** of an invalid result token will cause an exception to be thrown.
  ** 
- ** @see backend::ThreadJoinable usage example
+ ** @see vault::ThreadJoinable usage example
  */
 
 

src/lib/scoped-ptrvect.hpp

@@ -39,7 +39,7 @@
  ** 
  ** @see scoped-ptrvect-test.cpp
  ** @see scoped-holder.hpp
- ** @see gui::DisplayService usage example
+ ** @see stage::DisplayService usage example
  */
 
 

src/lib/test/microbenchmark.hpp

@@ -87,7 +87,7 @@ namespace test{
   inline double
   microbenchmark(FUN const& subject, const size_t nRepeat = DEFAULT_RUNS)
   {
-    using backend::ThreadJoinable;
+    using vault::ThreadJoinable;
     using std::chrono::system_clock;
     
     using Dur = std::chrono::duration<double>;

src/lib/wrapperptr.hpp

@@ -68,7 +68,7 @@ namespace lumiera {
    * @deprecated not sure if this was a good idea anyway. Better re-think how to handle wrapped objects in visitation
    * @todo really need to switch to the new lib::Variant and util::AccessCasted implementation  ////////////////TICKET #450
    */
-  typedef lib::VariantO<proc::WrapperTypes, util::AccessCasted_O> WrapperPtr;
+  typedef lib::VariantO<steam::WrapperTypes, util::AccessCasted_O> WrapperPtr;
   
   
   

src/lumiera/main.cpp

@@ -44,13 +44,13 @@ using lumiera::Subsys;
 using lumiera::AppState;
 
 namespace {
-  Subsys& engine  = backend::EngineFacade::getDescriptor();
-  Subsys& netNode = backend::NetNodeFacade::getDescriptor();
-  Subsys& script  = backend::ScriptRunnerFacade::getDescriptor();
+  Subsys& engine  = vault::EngineFacade::getDescriptor();
+  Subsys& netNode = vault::NetNodeFacade::getDescriptor();
+  Subsys& script  = vault::ScriptRunnerFacade::getDescriptor();
   Subsys& player  = lumiera::DummyPlayer::getDescriptor();        ///////TODO: just a dummy, until we're able to render
-  Subsys& session = proc::Facade::getSessionDescriptor();
-  Subsys& playOut = proc::Facade::getPlayOutDescriptor();
-  Subsys& lumigui = gui::GuiFacade::getDescriptor();
+  Subsys& session = steam::Facade::getSessionDescriptor();
+  Subsys& playOut = steam::Facade::getPlayOutDescriptor();
+  Subsys& lumigui = stage::GuiFacade::getDescriptor();
 }
 
 

src/stage/ctrl/bus-term.hpp

@@ -23,7 +23,7 @@
 
 /** @file bus-term.hpp
  ** Attachment point to the UI-Bus.
- ** Every gui::model::Tangible holds a BusTerm, which is linked
+ ** Every stage::model::Tangible holds a BusTerm, which is linked
  ** to the Tangible's identity, and serves to relay interface actions
  ** towards the Steam-Layer, to remember state changes and to broadcast
  ** notifications. Moreover, the BusTerm is the service point
@@ -107,7 +107,7 @@ namespace ctrl{
     {
     protected:
       using EntryID = lib::idi::BareEntryID;
-      using Tangible = gui::model::Tangible;
+      using Tangible = stage::model::Tangible;
       
       EntryID endpointID_;
       BusTerm& theBus_;

src/stage/ctrl/core-service.hpp

@@ -35,7 +35,7 @@
  ** CoreService is a PImpl to manage all the technical parts of actual
  ** service provision. When it goes down, all services are decommissioned.
  ** A part of these lifecycle technicalities is to manage the setup of the
- ** [UI-Bus main hub](\ref gui::ctrl::Nexus), which requires some trickery,
+ ** [UI-Bus main hub](\ref stage::ctrl::Nexus), which requires some trickery,
  ** since both CoreService and Nexus are mutually interdependent from an
  ** operational perspective, since they exchange messages in both directions.
  ** 
@@ -98,7 +98,7 @@
 namespace stage {
 namespace ctrl{
   
-  using proc::control::SessionCommand;
+  using steam::control::SessionCommand;
   using lib::diff::Rec;
   
   
@@ -109,7 +109,7 @@ namespace ctrl{
    * - commands need to be sent down to Steam-Layer
    * - presentation state messages need to be recorded and acted upon.
    * As an object, CoreService encases the heart of the UI-Bus, the
-   * \ref Nexus, and acts as "PImpl" for the gui::UiBus front-end.
+   * \ref Nexus, and acts as "PImpl" for the stage::UiBus front-end.
    */
   class CoreService
     : public BusTerm

src/stage/ctrl/state-recorder.hpp

@@ -67,7 +67,7 @@
 namespace stage {
 namespace ctrl {
   
-  using gui::ctrl::BusTerm;
+  using stage::ctrl::BusTerm;
   using lib::diff::GenNode;
   using lib::diff::Ref;
   using std::string;
@@ -81,7 +81,7 @@ namespace ctrl {
    * Requires a permanent connection to the UI-Bus,
    * which is given as reference at construction.
    * The intention is to use such an implementation
-   * embedded within the gui::ctrl::CoreService,
+   * embedded within the stage::ctrl::CoreService,
    * which in turn then manages the lifecycle of
    * this UI-Bus connection. Besides, a derived
    * mock implementation is available through

src/stage/dialog/test-control.hpp

@@ -128,7 +128,7 @@ namespace dialog {
    * - define the wiring of the components within a page in the page's ctor
    * - possibly pass external dependencies for wiring into that ctor
    * @note the page widgets are actually heap allocated and managed automatically
-   * @see gui::dialog::TestControl as a usage example
+   * @see stage::dialog::TestControl as a usage example
    * 
    * [Notebook]: https://developer.gnome.org/gtkmm-tutorial/stable/sec-multi-item-containers.html.en#sec-notebook
    */
@@ -266,13 +266,13 @@ namespace dialog {
               
               // define the action triggers...
               trig_1_.signal_clicked().connect(
-                          [&]{ bus.act (model::commandMessage (proc::cmd::test_meta_displayInfo, getLogLevel(), getContent())); });
+                          [&]{ bus.act (model::commandMessage (steam::cmd::test_meta_displayInfo, getLogLevel(), getContent())); });
               trig_2_.signal_clicked().connect(
-                          [&]{ bus.act (model::commandMessage (proc::cmd::test_meta_markError,   getContent()));                });
+                          [&]{ bus.act (model::commandMessage (steam::cmd::test_meta_markError,   getContent()));                });
               trig_3_.signal_clicked().connect(
-                          [&]{ bus.act (model::commandMessage (proc::cmd::test_meta_markNote,    getContent()));                });
+                          [&]{ bus.act (model::commandMessage (steam::cmd::test_meta_markNote,    getContent()));                });
               trig_4_.signal_clicked().connect(
-                          [&]{ bus.act (model::commandMessage (proc::cmd::test_meta_markAction,  getActionID(), getContent())); });
+                          [&]{ bus.act (model::commandMessage (steam::cmd::test_meta_markAction,  getActionID(), getContent())); });
             }
         };
       
@@ -328,9 +328,9 @@ namespace dialog {
               
               // define the action triggers...
               seq_1_.signal_clicked().connect(
-                          [&]{ bus.act (model::commandMessage (proc::cmd::test_fake_injectSequence_1, pickDummyID())); });
+                          [&]{ bus.act (model::commandMessage (steam::cmd::test_fake_injectSequence_1, pickDummyID())); });
               seq_2_.signal_clicked().connect(
-                          [&]{ bus.act (model::commandMessage (proc::cmd::test_fake_injectSequence_2, pickDummyID())); });
+                          [&]{ bus.act (model::commandMessage (steam::cmd::test_fake_injectSequence_2, pickDummyID())); });
               
               mut_1_.signal_clicked().connect(
                           [&]{ cerr << "gelldaschaugst..." <<endl; });

src/stage/display-service.hpp

@@ -42,7 +42,7 @@
  **
  ** @see lumiera::Display
  ** @see lumiera::DummyPlayer
- ** @see gui::PlaybackController usage example 
+ ** @see stage::PlaybackController usage example 
  */
 
 

src/stage/gtk-base.hpp

@@ -46,8 +46,8 @@
  **          for sake of compilation times and (debug) executable size.
  ** 
  ** @see gtk-lumiera.cpp the plugin to pull up this GUI
- ** @see gui::GuiFacade access point for starting the GUI
- ** @see gui::GuiNotification interface for communication with the gui from the lower layers
+ ** @see stage::GuiFacade access point for starting the GUI
+ ** @see stage::GuiNotification interface for communication with the gui from the lower layers
  ** @see lumiera::Config
  ** @see lumiera::BasicSetup definition of the acceptable configuration values
  ** @see lumiera::AppState general Lumiera application main

src/stage/gtk-lumiera.cpp

@@ -27,7 +27,7 @@
  ** Start up the Lumiera GTK GUI when loading it as dynamic module.
  ** This plugin is linked together with the Lumiera GUI code; when loaded as
  ** Lumiera plugin, it allows to kick off the GTK main event loop and thus to bring
- ** up the GUI. The loading and shutdown process is carried out by gui::GuiFacade and
+ ** up the GUI. The loading and shutdown process is carried out by stage::GuiFacade and
  ** controlled by lumiera::AppState, which in turn is activated by Lumiera main().
  ** 
  ** After successfully loading this module, a call to GuiFacade::launchUI is expected to
@@ -38,10 +38,10 @@
  ** the main GTK event loop. Before entering this loop, the CoreService of the GUI and
  ** especially the [UI-Bus](\ref ui-bus.hpp) is started see \ref GtkLumiera::run().
  ** This entails also to open the primary "business" interface(s) of the GUI
- ** (currently as of 1/16 this is the interface gui::GuiNotification.)
+ ** (currently as of 1/16 this is the interface stage::GuiNotification.)
  ** 
  ** @see lumiera::AppState
- ** @see gui::GuiFacade
+ ** @see stage::GuiFacade
  ** @see guifacade.cpp
  ** @see ui-manager.hpp
  */
@@ -65,10 +65,10 @@ extern "C" {
 
 
 
-using backend::Thread;
+using vault::Thread;
 using lumiera::Subsys;
 using lumiera::error::LUMIERA_ERROR_STATE;
-using gui::LUMIERA_INTERFACE_INAME(lumieraorg_Gui, 1);
+using stage::LUMIERA_INTERFACE_INAME(lumieraorg_Gui, 1);
 
 using std::string;
 
@@ -246,7 +246,7 @@ extern "C" { /* ================== define a lumieraorg_Gui instance ============
                                           , LUMIERA_INTERFACE_INLINE (launchUI,
                                                                       bool, (void* termSig),
                                                                         {
-                                                                          return gui::launchUI (*reinterpret_cast<Subsys::SigTerm *> (termSig));
+                                                                          return stage::launchUI (*reinterpret_cast<Subsys::SigTerm *> (termSig));
                                                                         }
                                                                      )
                                           )

src/stage/guifacade.hpp

@@ -55,7 +55,7 @@ namespace stage {
    * Global access point for loading and starting up the Lumiera GTK GUI
    * and for controlling the GUI lifecycle. The implementation part of
    * this class also is responsible for making the "business" interface
-   * of the GUI available, i.e. gui::GuiNotification
+   * of the GUI available, i.e. stage::GuiNotification
    * 
    * When running Lumiera with a GUI is required (the default case),
    * it is loaded as dynamic module, thus defining the interface(s) 
@@ -69,11 +69,11 @@ namespace stage {
    * is somewhat special, as its sole purpose is to expose the subsystem
    * descriptor, which, when started, loads the GUI as a plugin and
    * invokes `launchUI(term)` there. For the implementation see
-   * gui::GuiRunner (guifacade.cpp) and gtk-lumiera.cpp (the plugin).
+   * stage::GuiRunner (guifacade.cpp) and gtk-lumiera.cpp (the plugin).
    * 
    * @note this facade is intended to be used by Lumiera main solely.
    *       client code should always use the "business" interface(s):
-   *       - gui::GuiNotification
+   *       - stage::GuiNotification
    * 
    */
   class GuiFacade

src/stage/id-scheme.hpp

@@ -97,7 +97,7 @@ namespace stage {
     template<>
     struct Descriptor<TimelineView>
       {
-        using Model = proc::asset::Timeline;
+        using Model = steam::asset::Timeline;
       };
     
     
@@ -107,7 +107,7 @@ namespace stage {
     template<>
     struct Descriptor<ErrorLogView>
       {
-        using Model = proc::asset::meta::ErrorLog;
+        using Model = steam::asset::meta::ErrorLog;
         
         ///////////////////////////////////////////////////////////////////////////////////////////TICKET #1105 : consider use of a DSL to configure component view access 
         //

src/stage/interact/interaction-director.cpp

@@ -76,8 +76,8 @@ using util::toString;
 namespace stage {
 namespace interact {
   
-  namespace session = proc::mobject::session;
-  namespace cmd = proc::cmd;
+  namespace session = steam::mobject::session;
+  namespace cmd = steam::cmd;
   
   using ctrl::GlobalCtx;
   using ctrl::UiState;
@@ -188,7 +188,7 @@ namespace interact {
   void
   InteractionDirector::saveSnapshot()
   {
-    string snapshotID{"snap-" + toString(backend::RealClock::now())};
+    string snapshotID{"snap-" + toString(vault::RealClock::now())};
     invoke (cmd::session_saveSnapshot, snapshotID);
   }
   
@@ -277,7 +277,7 @@ namespace interact {
   InteractionDirector::newSequence()
   {
     LuidH anchor{*this};                    /////////////////////////////////////////////////////////////////TICKET #1082 : actually access the interaction state to get "current scope"
-    LuidH newSeqID{EntryID<proc::asset::Sequence>().getHash()};  ////////////////////////////////////////////TICKET #1096 : a better Idea what to send over the wire?
+    LuidH newSeqID{EntryID<steam::asset::Sequence>().getHash()};  ////////////////////////////////////////////TICKET #1096 : a better Idea what to send over the wire?
     invoke (cmd::session_newSequence, anchor, newSeqID);
   }
   
@@ -301,7 +301,7 @@ namespace interact {
   InteractionDirector::newTrack()
   {
     LuidH anchor{*this};                    /////////////////////////////////////////////////////////////////TICKET #1082 : actually access the interaction state to get "current scope"
-    LuidH newTrackID{EntryID<proc::mobject::session::Fork>().getHash()};  ///////////////////////////////////TICKET #1096 : a better Idea what to send over the wire?
+    LuidH newTrackID{EntryID<steam::mobject::session::Fork>().getHash()};  ///////////////////////////////////TICKET #1096 : a better Idea what to send over the wire?
     invoke (cmd::sequence_newTrack, anchor, newTrackID);
   }
   

src/stage/interact/ui-coord-resolver.hpp

@@ -43,7 +43,7 @@
  **   the next level of child iteration at its place, similar to the `flatMap`
  **   operation known from functional programming.
  ** Together, these two capabilities allow us to build exploring and backtracking evaluations,
- ** which is enough to build a secondary helper component on top, the gui::interact::UICoordResolver
+ ** which is enough to build a secondary helper component on top, the stage::interact::UICoordResolver
  ** 
  ** 
  ** # UI coordinate path evaluation
@@ -53,7 +53,7 @@
  ** followed by traversal of the coordinate spec and matching against a navigation path within the actual UI window
  ** configuration. This process might involve interpretation of some meta-symbols and interpolation of wildcards.
  ** 
- ** As indicated above, the coordinate resolver internally relies on a [context query interface](\ref gui::interact::LocationQuery),
+ ** As indicated above, the coordinate resolver internally relies on a [context query interface](\ref stage::interact::LocationQuery),
  ** to find out about existing windows, panels, views and tabs and to navigate the real UI structure. The actual
  ** implementation of this context query interface is backed by the \ref Navigator component exposed through the
  ** \ref InteractionDirector.

src/stage/interact/view-locator.cpp

@@ -53,9 +53,9 @@
 //using util::cStr;
 //using util::isnil;
 using lib::Symbol;
-//using gui::ctrl::PanelLocator;
-//using gui::ctrl::WindowLocator;
-using gui::model::ElementAccess;
+//using stage::ctrl::PanelLocator;
+//using stage::ctrl::WindowLocator;
+using stage::model::ElementAccess;
 
 
 namespace stage {

src/stage/interact/view-locator.hpp

@@ -42,7 +42,7 @@
  ** thus relies on a framework for default configuration, and a matching mechanism to determine the location and
  ** creation modes of such views. This matching mechanism in turn requires an abstracted view on the UI seen as
  ** a topological tree structure of relevant entities (windows, panels, views,...) -- which is basically the
- ** service provided by the Navigator; yet this Navigator service can be abstracted into the gui::interact::LocationQuery
+ ** service provided by the Navigator; yet this Navigator service can be abstracted into the stage::interact::LocationQuery
  ** API, and this abstraction allows to keep all the intricacies of navigating concrete UI widgets confined within the
  ** implementation of the Navigator service.
  ** 

src/stage/interact/view-spec-dsl.hpp

@@ -276,7 +276,7 @@ namespace idi {
    * These are (singleton) instances of idi::Descriptor<V>, and assumed to expose
    * - a member `viewSpec.locate`, which solves for the actual view location within UI topology
    * - a member `viewSpec.alloc`, which actually claims / allocates an existing or new view instance
-   * @see gui::ctrl::ViewLocator::get
+   * @see stage::ctrl::ViewLocator::get
    */
   template<class VIEW>
   inline Descriptor<VIEW>&

src/stage/interact/wizard.hpp

@@ -96,7 +96,7 @@ namespace interact {
       void show_HelpAbout();
       void launchTestCtrl();
       
-      static ID getErrorLogID() { return proc::asset::meta::theErrorLog_ID; }
+      static ID getErrorLogID() { return steam::asset::meta::theErrorLog_ID; }
       
     private:
     };

src/stage/model/controller.hpp

@@ -29,7 +29,7 @@
  **       especially, there might be a default (NOP) implementation of the diff mutator builder
  ** 
  ** @see model::Tangible
- ** @see gui::UIBus
+ ** @see stage::UIBus
  ** @see ////TODO_test usage example
  ** 
  */

src/stage/model/element-access.hpp

@@ -80,7 +80,7 @@ namespace model {
   /**
    * Interface: access UI elements by navigating the UI topology.
    * 
-   * @see gui::interact::Navigator
+   * @see stage::interact::Navigator
    * @see ElementAccess_test
    */
   class ElementAccess

src/stage/model/flash-deco.hpp

@@ -53,7 +53,7 @@ namespace model {
    * Decorator for a Gtk::Widget to add a visual flash action.
    * @tparam WIT type of the target widget to decorate. All ctors are passed through.
    * @remark invoke the #flash function to trigger
-   * @see \ref gui::CSS_CLASS_FLASH
+   * @see \ref stage::CSS_CLASS_FLASH
    */
   template<class WIT>
   class FlashDeco

src/stage/model/widget.hpp

@@ -26,7 +26,7 @@
  ** 
  ** @todo as of 1/2015 this is complete WIP-WIP-WIP
  ** 
- ** @see gui::model::Tangible
+ ** @see stage::model::Tangible
  ** @see ////TODO_test usage example
  ** 
  */

src/stage/notification-service.cpp

@@ -76,8 +76,8 @@ extern "C" {
 using lib::diff::GenNode;
 using lib::diff::TreeMutator;
 using lib::diff::MutationMessage;
-using gui::ctrl::UiDispatcher;
-using gui::ctrl::BusTerm;
+using stage::ctrl::UiDispatcher;
+using stage::ctrl::BusTerm;
 using util::cStr;
 using util::_Fmt;
 

src/stage/notification-service.hpp

@@ -21,18 +21,18 @@
 */
 
 /** @file notification-service.hpp
- ** A public service provided by the GUI, implementing the gui::GuiNotification facade interface.
+ ** A public service provided by the GUI, implementing the stage::GuiNotification facade interface.
  ** The purpose of this service is to push state update and notification of events from the lower
  ** layers into the Lumiera GUI. Typically, this happens asynchronously and triggered either by
  ** events within the lower layers, or as result of invoking commands on the session.
  ** 
  ** This service is the implementation of a layer separation facade interface. Clients should use
- ** gui::GuiNotification#facade to access this service. This header here defines the interface
+ ** stage::GuiNotification#facade to access this service. This header here defines the interface
  ** used to _provide_ this service, not to access it.
  ** 
- ** @see gui::GuiFacade launching the Lumiera UI
+ ** @see stage::GuiFacade launching the Lumiera UI
  ** @see facade.hpp RAII holder to start this service and open the interface
- ** @see gui::ctrl::UiManager::performMainLoop() exposes all UI façade interfaces
+ ** @see stage::ctrl::UiManager::performMainLoop() exposes all UI façade interfaces
  */
 
 

src/stage/panel/timeline-panel-obsolete.cpp

@@ -39,8 +39,8 @@ using namespace stage::widget;
 using namespace stage::widget::timeline;
 using namespace stage::model;
 
-using gui::controller::Controller;
-using gui::ctrl::PlaybackController;
+using stage::controller::Controller;
+using stage::ctrl::PlaybackController;
 using std::shared_ptr;
 using std::weak_ptr;
 using util::contains;
@@ -70,7 +70,7 @@ namespace panel {
     , zoomOut(Stock::ZOOM_OUT)
     , zoomScale()
     , updatingToolbar(false)
-    , currentTool(gui::widget::timeline::Arrow)
+    , currentTool(stage::widget::timeline::Arrow)
     {
       // Hook up notifications
       obsoleteProject_.get_sequences().signal_changed().connect(mem_fun(this,
@@ -184,13 +184,13 @@ namespace panel {
   void
   TimelinePanelObsolete::on_arrow_tool()
   {
-    setTool(gui::widget::timeline::Arrow);
+    setTool(stage::widget::timeline::Arrow);
   }
   
   void
   TimelinePanelObsolete::on_ibeam_tool()
   {  
-    setTool(gui::widget::timeline::IBeam);
+    setTool(stage::widget::timeline::IBeam);
   }
   
   void
@@ -329,8 +329,8 @@ namespace panel {
     if (!updatingToolbar)
       {
         updatingToolbar = true;
-        arrowTool.set_active (currentTool == gui::widget::timeline::Arrow);
-        iBeamTool.set_active (currentTool == gui::widget::timeline::IBeam);
+        arrowTool.set_active (currentTool == stage::widget::timeline::Arrow);
+        iBeamTool.set_active (currentTool == stage::widget::timeline::IBeam);
         updatingToolbar = false;
       }
   }

src/stage/panel/timeline-panel-obsolete.hpp

@@ -114,7 +114,7 @@ namespace model{
       
       bool is_playing();
       
-      void setTool (gui::widget::timeline::ToolType tool);
+      void setTool (stage::widget::timeline::ToolType tool);
       
       void showTime (Time);
         
@@ -188,13 +188,13 @@ namespace model{
       
       MiniButton zoomIn;
       MiniButton zoomOut;
-      gui::widget::timeline::TimelineZoomScale zoomScale;
+      stage::widget::timeline::TimelineZoomScale zoomScale;
       
       Gtk::SeparatorToolItem separator2;
       
       // Internals
       bool updatingToolbar;
-      gui::widget::timeline::ToolType currentTool;
+      stage::widget::timeline::ToolType currentTool;
       
     private:
       // TEST CODE

src/stage/panel/timeline-panel.hpp

@@ -30,8 +30,8 @@
  ** manages a collection of timelines. The timeline panel exposes this collection and allows to view and
  ** interact with one of the given timelines. The build-up of the timeline display and thus the initiative
  ** to expose a timeline comes from the interaction director -- but as usual with graphical user interfaces,
- ** any user interaction after this point is handled autonomously by the gui::timeline::TimelineWidget and
- ** gui::timeline::TimelineController
+ ** any user interaction after this point is handled autonomously by the stage::timeline::TimelineWidget and
+ ** stage::timeline::TimelineController
  ** 
  ** @todo as of 10/2016 this is WIP-WIP-WIP : canvas widgets experiment
  ** @todo as of 10/2018 we start to build a new timeline widget, connected to the UI-Bus

src/stage/setting/asset-controller.hpp

@@ -40,8 +40,8 @@
  ** 
  ** @todo WIP 2/2017 early draft / a new UI backbone
  ** 
- ** @see proc::mobject::Session
- ** @see proc::asset::Asset
+ ** @see steam::mobject::Session
+ ** @see steam::asset::Asset
  ** @see timeline-controller.hpp
  ** @see interaction-director.hpp
  ** @see ui-bus.hpp

src/stage/style-scheme.cpp

@@ -24,7 +24,7 @@
 /** @file style-scheme.hpp
  ** Definition of access keys for uniform UI styling.
  ** 
- ** @see gui::workspace::UiStyle
+ ** @see stage::workspace::UiStyle
  ** 
  */
 

src/stage/timeline/clip-presenter.hpp

@@ -30,7 +30,7 @@
  ** as known from the [MVP pattern](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter) --
  ** serves as link between both levels. For the global angle of view, it is a model::Tangible and thus
  ** plays the role of the _View_, while the _Model_ and _Controler_ roles are mediated through the
- ** gui::UiBus, exchanging command, state and mutation messages. On the other hand, for the local
+ ** stage::UiBus, exchanging command, state and mutation messages. On the other hand, for the local
  ** angle of view, the _Presenter_ is a structural model element, kind of a _view model_, and corresponds
  ** to the respective element within the session. In addition, it manages actively the collaborative
  ** part of layout building, delegating to a mostly passive GTK widget for the actual display.

src/stage/timeline/timeline-controller.cpp

@@ -130,7 +130,7 @@ namespace timeline {
    *   as a nested scope.
    * For both cases we prepare a way to build a _nested mutator_, and in both cases this
    * is simply achieved by relying on the common interface of all those "elements", which
-   * is gui::model::Tangible and just happens to require each such "tangible" to offer
+   * is stage::model::Tangible and just happens to require each such "tangible" to offer
    * a mutation building method, just like this one here. Simple recursive programming.
    * @see DiffComplexApplication_test
    */

src/stage/timeline/timeline-gui.cpp

@@ -27,8 +27,8 @@
  ** actual object construction are defined within this dedicated translation unit.
  ** 
  ** @see TimelineWidget
- ** @see gui::interact::InteractionDirector::buildMutator
- ** @see gui::timeline::TimelineController::buildMutator
+ ** @see stage::interact::InteractionDirector::buildMutator
+ ** @see stage::timeline::TimelineController::buildMutator
  ** 
  */
 
@@ -88,7 +88,7 @@ namespace timeline {
    *    unique_ptr<TimelinePage> right here, which can than be handed over to TimelinePanel,
    *    yet still we _do inherit_ from WLink<TimelineWidget>, i.e. expose the subclass.
    *    The `unque_ptr` owns and manages the TimelineWidget, which is itself non-copyable
-   *    and stays at a fixed location in heap memory, as is required by gui::ctrl::Nexus
+   *    and stays at a fixed location in heap memory, as is required by stage::ctrl::Nexus
    *    to maintain a registration of the UI-Bus connection. WLink to the contrary
    *    just connects to the widget, and is automatically disconnected when it dies.
    */

src/stage/timeline/timeline-gui.hpp

@@ -43,8 +43,8 @@
  ** initially, or in answer to a population request originating from within the UI, prompted by the
  ** need to expose some timeline at a given place within the interface.
  ** 
- ** @see gui::interact::InteractionDirector::buildMutator
- ** @see gui::timeline::TimelineWidget
+ ** @see stage::interact::InteractionDirector::buildMutator
+ ** @see stage::timeline::TimelineWidget
  ** 
  */
 

src/stage/timeline/timeline-widget.hpp

@@ -36,7 +36,7 @@
  ** # Lifecycle
  ** The assumption is that any element creation and deletion is triggered through messages over
  ** the [UI-Bus](\ref ui-bus.hpp). So there will be a _parent element,_ corresponding to the
- ** [model root](\ref proc::mobject::session::Root), and this parent, in response to some
+ ** [model root](\ref steam::mobject::session::Root), and this parent, in response to some
  ** mutation message, will create a TimelineWidget, add it into the appropriate GTK display setup
  ** and manage it as child element; the [construction parameters](\ref TimelineWidget::TimelineWidget)
  ** ensure it gets connected to the bus as well. Incidentally, this assumption also implies that
@@ -128,7 +128,7 @@ namespace timeline {
        *          the one that created it, typically also in response to a message.
        *          Non the less it is possible just to delete a TimelineWidget, since
        *          it is a Gtk::Widget, and the controller is also `sigc::trackable`
-       *          and additionally, as a gui::model::Tangible, it will deregister
+       *          and additionally, as a stage::model::Tangible, it will deregister
        *          automatically from the UI-Bus. After that, any further messages
        *          towards this element will be dropped silently.
        */

src/stage/timeline/track-presenter.hpp

@@ -30,7 +30,7 @@
  ** as known from the [MVP pattern](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter) --
  ** serves as link between both levels. For the global angle of view, it is a model::Tangible and thus
  ** plays the role of the _View_, while the _Model_ and _Controler_ roles are mediated through the
- ** gui::UiBus, exchanging command, state and mutation messages. On the other hand, for the local
+ ** stage::UiBus, exchanging command, state and mutation messages. On the other hand, for the local
  ** angle of view, the _Presenter_ is a structural model element, kind of a _view model_, and corresponds
  ** to the respective element within the session. In addition, it manages actively the collaborative
  ** part of layout building, delegating to a mostly passive GTK widget for the actual display.

src/stage/ui-bus.cpp

@@ -26,7 +26,7 @@
  ** Implementation of the UI backbone service for messaging.
  ** Any globally relevant widget or controller within the Lumiera UI
  ** is connected to the [UI-Bus](\ref ui-bus.hpp), which is essentially implemented
- ** within this compilation unit. [Clients](\ref gui::model::Tangible) typically
+ ** within this compilation unit. [Clients](\ref stage::model::Tangible) typically
  ** use the [BusTerm-Interface](\ref bus-term.hpp) to route generic actions and
  ** receive notifications, state changes and mutations.
  ** 
@@ -123,7 +123,7 @@ namespace ctrl {
      * @remarks some commands can simply be invoked right away, but
      *          in the general case, a command needs to be prepared with
      *          suitable arguments prior to being invoked, which can be
-     *          a multi-step process. The gui::interact::InteractionState
+     *          a multi-step process. The stage::interact::InteractionState
      *          is used to conduct this argument binding process from within
      *          the UI. Here, at the UI-Bus interface, we're just interested
      *          in the fact _that_ some command is to be bound and invoked.
@@ -132,8 +132,8 @@ namespace ctrl {
      * @note no information regarding the _origin_ of this command invocation
      *          is captured. If a command needs a _subject_, this has to be
      *          bound as an command argument beforehand.
-     * @see gui::model::Tangible::issueCommand()
-     * @see proc::control::SessionCommand
+     * @see stage::model::Tangible::issueCommand()
+     * @see steam::control::SessionCommand
      */
     void
     BusTerm::act (GenNode const& command)
@@ -164,9 +164,9 @@ namespace ctrl {
     /** route a state update or notification to the given subject.
      * @param subject the [endpoint-ID](\ref BusTerm::endpointID_) of the element to address
      * @param mark the actual state update or notification message to be delivered
-     * @remarks each addressed "subject" is a gui::model::Tangible, and as such holds
+     * @remarks each addressed "subject" is a stage::model::Tangible, and as such holds
      *          a BusTerm of its own, which in turn ensures a registration and connection
-     *          from the [central routing hub](\ref gui::ctrl::Nexus) down to the element. Thus,
+     *          from the [central routing hub](\ref stage::ctrl::Nexus) down to the element. Thus,
      *          the default implementation is just to pass the given state mark "up",
      *          assuming that it will reach the hub eventually, which in turn knows
      *          how to reach the element, and invoke the Tangible::mark() operation.

src/stage/ui-bus.hpp

@@ -26,7 +26,7 @@
  ** The Lumiera GTK GUI is built around a generic backbone structure known as **UI-Bus**.
  ** This is a messaging system and taps into any widget of more than local relevance.
  ** To that end, any globally relevant (custom) widget, and all secondary controllers
- ** inherit from the gui::model::Tangible base. The top-level gui::UiBus element is
+ ** inherit from the stage::model::Tangible base. The top-level stage::UiBus element is
  ** a front-end and framework component managed by the [GTK-main](\ref GtkLumiera::main).
  ** 
  ** @warning as of 12/2016, this is still totally a mess. This \em will remain
@@ -68,7 +68,7 @@
  ** 
  ** - *act*: send a [GenNode] representing the action
  **   - the ID is either a globally registered command-ID or an explicitly
- **     ["opened"](\ref proc::control::SessionCommand::cycle(Symbol,string)) command instance ID.
+ **     ["opened"](\ref steam::control::SessionCommand::cycle(Symbol,string)) command instance ID.
  **   - the payload is a Record<GenNode> holding the actual command arguments
  **   - on reception, an _instance_ (anonymous clone copy) of the command is created, bound
  **     with the arguments and handed over to the ProcDispatcher to be enqueued for execution.

src/stage/widget/bin-widget.hpp

@@ -27,7 +27,7 @@
  ** to organise various "things", like clips, media, effect plugins, labels
  ** sequences, processing patterns and also other nested bins. In the Lumiera
  ** session model, media bins and tracks are visual renderings of the same entity,
- ** a [grouping fork](\ref proc::mobject::session::Fork). This wide array of
+ ** a [grouping fork](\ref steam::mobject::session::Fork). This wide array of
  ** possible usage gives rise to some complexity and several display styles, ranging
  ** from a simple list to a working area to arrange elements, with drag-n-drop
  ** support, searching and establishing of an element order. The generality

src/stage/widget/button-bar.cpp

@@ -47,4 +47,4 @@ namespace widget {
   }
   
   
-}}// gui::widget
+}}// stage::widget

src/stage/widget/button-bar.hpp

@@ -60,5 +60,5 @@ namespace widget {
     };
   
   
-}}// gui::widget
+}}// stage::widget
 #endif /*STAGE_WIDGET_BUTTON_BAR_H*/

src/stage/widget/error-log-display.hpp

@@ -273,7 +273,7 @@ namespace widget {
       
       /** temporarily change display style to prompt for attention;
        *  set callback-timeout for return to normal state.
-       * @see \ref gui::CSS_CLASS_FLASH
+       * @see \ref stage::CSS_CLASS_FLASH
        */
       void
       triggerFlash()

src/stage/widget/menu-button.cpp

@@ -206,4 +206,4 @@ namespace widget {
   }
   
   
-}}// gui::widget
+}}// stage::widget

src/stage/widget/menu-button.hpp

@@ -169,5 +169,5 @@ namespace widget {
     };
   
   
-}}// gui::widget
+}}// stage::widget
 #endif /*STAGE_WIDGET_MENU_BUTTON_H*/

src/stage/widget/mini-button.hpp

@@ -86,5 +86,5 @@ namespace widget {
   
   
   
-}}// gui::widget
+}}// stage::widget
 #endif /*STAGE_WIDGET_MINI_BUTTON_H*/

src/stage/widget/panel-bar.cpp

@@ -162,4 +162,4 @@ namespace widget {
   }
   
   
-}}// gui::widget
+}}// stage::widget

src/stage/widget/panel-bar.hpp

@@ -113,5 +113,5 @@ namespace stage {
   
   
   
-}}// gui::widget
+}}// stage::widget
 #endif /*STAGE_WIDGET_PANEL_BAR_H*/

src/stage/widget/timecode-widget.cpp

@@ -1404,4 +1404,4 @@ namespace widget {
   
   
   
-}}// gui::widget
+}}// stage::widget

src/stage/widget/timecode-widget.hpp

@@ -217,5 +217,5 @@ namespace widget {
   
   
   
-}}// gui::widget
+}}// stage::widget
 #endif /*STAGE_WIDGET_TIMECODE_WIDGET_H*/

src/stage/widget/timeline-widget.cpp

@@ -24,7 +24,7 @@
 /** @file widget/timeline-widget.cpp
  ** 
  ** @deprecated as of 11/2016, a complete rework of the timeline display is underway
- ** @see gui::timeline::TimelineWidget new timeline display
+ ** @see stage::timeline::TimelineWidget new timeline display
  ** 
  */
 
@@ -556,4 +556,4 @@ namespace widget {
   }
   
   
-}}// gui::widget
+}}// stage::widget

src/stage/widget/timeline-widget.hpp

@@ -30,7 +30,7 @@
  **       Moreover, this class is designed way to monolithic.
  **       It will never be able to scale to the full planned
  **       timeline and editing functionality of Lumiera
- ** @see gui::timeline::TimelineWidget new timeline display
+ ** @see stage::timeline::TimelineWidget new timeline display
  */
 
 
@@ -63,7 +63,7 @@ namespace widget {
   
   /** namespace of timeline widget helper classes.
    * @deprecated as of 11/2016, a complete rework of the timeline display is underway
-   * @see (\ref gui::timeline) namespace of the new timeline display
+   * @see (\ref stage::timeline) namespace of the new timeline display
    */
   namespace timeline {}
   
@@ -310,5 +310,5 @@ namespace widget {
     };
   
   
-}}// gui::widget
+}}// stage::widget
 #endif /*STAGE_WIDGET_TIMELINE_WIDGET_H*/

src/stage/widget/timeline/timeline-body.cpp

@@ -42,7 +42,7 @@ using namespace Gtk;         ///////////////////////////////////////////////////
 using namespace std;         ///////////////////////////////////////////////////////////////////////////////TICKET #1071 no wildcard includes please!
 using namespace lumiera;     ///////////////////////////////////////////////////////////////////////////////TICKET #1071 no wildcard includes please!
 
-using gui::draw::CairoUtil;
+using stage::draw::CairoUtil;
 using std::shared_ptr;
 
 namespace stage {

src/stage/widget/timeline/timeline-body.hpp

@@ -68,7 +68,7 @@ public:
    * @param timeline_widget A reference to the owner widget of this
    * ruler.
    */
-  TimelineBody(gui::widget::TimelineWidget &timeline_widget);
+  TimelineBody(stage::widget::TimelineWidget &timeline_widget);
   
   virtual ~TimelineBody();
   
@@ -203,7 +203,7 @@ private:
   float selectionAlpha;
   Cairo::RefPtr<Cairo::SolidPattern> playbackPointColour;
   
-  gui::widget::TimelineWidget &timelineWidget;
+  stage::widget::TimelineWidget &timelineWidget;
   shared_ptr<TimelineState> timelineState;
   
 

src/stage/widget/timeline/timeline-header-container.cpp

@@ -53,7 +53,7 @@ namespace timeline {
   
   // ===== Implementation ===== //
   
-  TimelineHeaderContainer::TimelineHeaderContainer(gui::widget::TimelineWidget &timeline_widget)
+  TimelineHeaderContainer::TimelineHeaderContainer(stage::widget::TimelineWidget &timeline_widget)
     : Glib::ObjectBase("TimelineHeaderContainer")
     , timelineWidget(timeline_widget)
     {

src/stage/widget/timeline/timeline-header-container.hpp

@@ -56,7 +56,7 @@ namespace stage {
     : public Gtk::Container
     {
     public:
-      TimelineHeaderContainer(gui::widget::TimelineWidget &timeline_widget);
+      TimelineHeaderContainer(stage::widget::TimelineWidget &timeline_widget);
       
       /**
        * Attaches the header all the header widgets of root
@@ -216,7 +216,7 @@ namespace stage {
       /**
        * The owner TimelineWidget of which this class is a helper
        */
-      gui::widget::TimelineWidget &timelineWidget;
+      stage::widget::TimelineWidget &timelineWidget;
       
       /**
        * The widget's window object. 
@@ -267,7 +267,7 @@ namespace stage {
        */
       static const int ScrollSlideEventInterval;
       
-      friend class gui::widget::TimelineWidget;
+      friend class stage::widget::TimelineWidget;
       friend class timeline::Track;
     };
   

src/stage/widget/timeline/timeline-header-widget.cpp

@@ -239,7 +239,7 @@ namespace timeline {
     bool hovering = false;
     
     const Gdk::Rectangle box = get_allocation();
-    if (gui::draw::pt_in_rect (Gdk::Point(event->x, event->y),
+    if (stage::draw::pt_in_rect (Gdk::Point(event->x, event->y),
                                Gdk::Rectangle(margin, margin,
                                               expand_button_size,
                                               box.get_height() - margin * 2)))

src/stage/widget/timeline/timeline-layout-helper.cpp

@@ -119,7 +119,7 @@ namespace timeline {
     BOOST_FOREACH( pair, headerBoxes )
       {
         // Hit test the rectangle      
-        if (gui::draw::pt_in_rect (point, pair.second))
+        if (stage::draw::pt_in_rect (point, pair.second))
           return shared_ptr<timeline::Track>(pair.first);
       }
     

src/stage/widget/timeline/timeline-layout-helper.hpp

@@ -58,7 +58,7 @@ namespace stage {
    * A helper class for the TimelineWidget. TimelineLayoutHelper
    * is a class which calculates the layout of tracks in the timeline
    * track tree.
-   * @see gui::widget::TimelineWidget
+   * @see stage::widget::TimelineWidget
    */
   class TimelineLayoutHelper
     : util::NonCopyable

src/stage/widget/timeline/timeline-ruler.cpp

@@ -43,7 +43,7 @@ using namespace stage::widget;     /////////////////////////////////////////////
 using namespace stage::widget::timeline;     ///////////////////////////////////////////////////////////////////////////////TICKET #1071 no wildcard includes please!
 
 using std::shared_ptr;
-using gui::draw::CairoUtil;
+using stage::draw::CairoUtil;
 using lib::time::Time;
 using lib::time::TimeVar;
 

src/stage/widget/timeline/timeline-ruler.hpp

@@ -54,7 +54,7 @@ namespace widget {
     : public Gtk::DrawingArea
     {
     public:
-      TimelineRuler (gui::widget::TimelineWidget& timeline_widget);
+      TimelineRuler (stage::widget::TimelineWidget& timeline_widget);
       
       /**
        * Sets offset of the mouse chevron
@@ -235,7 +235,7 @@ namespace widget {
       /**
        * The owner widget
        */
-      gui::widget::TimelineWidget &timelineWidget;
+      stage::widget::TimelineWidget &timelineWidget;
       
       /**
        * the currently active timeline state object 

src/stage/widget/timeline/timeline-tool.cpp

@@ -89,10 +89,10 @@ namespace timeline {
   }
   
   
-  gui::widget::TimelineWidget&
+  stage::widget::TimelineWidget&
   Tool::get_timeline_widget()  const
   {
-    gui::widget::TimelineWidget &timeline_widget =
+    stage::widget::TimelineWidget &timeline_widget =
       timelineBody.timelineWidget;
     return timeline_widget;
   }

src/stage/widget/timeline/timeline-tool.hpp

@@ -126,7 +126,7 @@ namespace timeline {
        * Helper function which retrieves the pointer to owner timeline
        * widget object, which is the owner of the timeline body.
        */
-      gui::widget::TimelineWidget &get_timeline_widget()  const;
+      stage::widget::TimelineWidget &get_timeline_widget()  const;
       
       /**
        * Helper function which retrieves the rectangle of the timeline

src/stage/widget/video-display-widget.cpp

@@ -95,4 +95,4 @@ namespace widget {
   }
   
   
-}}// gui::widget
+}}// stage::widget

src/stage/widget/video-display-widget.hpp

@@ -69,5 +69,5 @@ namespace widget {
     };
   
   
-}}// gui::widget
+}}// stage::widget
 #endif /*STAGE_WIDGET_VIDEO_DISPLAY_WIDGET_H*/

src/steam/asset.hpp

@@ -356,11 +356,11 @@ namespace asset {
 
 namespace proc_interface {
   
-  using proc::asset::Asset;
-  using proc::asset::Category;
-  using proc::asset::ID;
-  using proc::asset::IDA;
-  using proc::asset::PAsset;
+  using steam::asset::Asset;
+  using steam::asset::Category;
+  using steam::asset::ID;
+  using steam::asset::IDA;
+  using steam::asset::PAsset;
 }
 
 #endif

src/steam/asset/media.hpp

@@ -76,8 +76,8 @@ namespace asset {
       
     public:
       using PMedia = lib::P<Media>;
-      using PClipAsset  = lib::P<proc::asset::Clip>;
-      using PProcPatt = lib::P<proc::asset::ProcPatt>;
+      using PClipAsset  = lib::P<steam::asset::Clip>;
+      using PProcPatt = lib::P<steam::asset::ProcPatt>;
       using PClip = mobject::Placement<mobject::session::Clip>;
      
       
@@ -123,7 +123,7 @@ namespace asset {
        *  @return pointer to parent, or `null`
        */
       virtual PMedia checkCompound ()  const;
-      friend class proc::asset::Clip;    ////////////////////////TODO better interface!!!
+      friend class steam::asset::Clip;    ////////////////////////TODO better interface!!!
 
     };
     

src/steam/asset/meta/error-log.hpp

@@ -28,11 +28,11 @@
  **       in order to mark the corresponding receiver widget in the UI. The idea is eventually
  **       to persist relevant messages, filtering them out as time passes. Such an incident log
  **       would be part of the session model, thus replicating its contents into the corresponding
- **       gui::widget::ErrorLogView -- which displays notifications without blocking the UI.
+ **       stage::widget::ErrorLogView -- which displays notifications without blocking the UI.
  ** 
  ** @see MetaFactory creating concrete asset::Meta instances
- ** @see gui::ctrl::NotificationHub corresponding UI controller
- ** @see gui::interact::Wizard information service in the UI
+ ** @see stage::ctrl::NotificationHub corresponding UI controller
+ ** @see stage::interact::Wizard information service in the UI
  **
  */
 

src/steam/asset/struct-factory-impl.hpp

@@ -73,14 +73,14 @@ namespace asset {
   using lumiera::query::LERR_(CAPABILITY_QUERY);
   using lib::query::extractID;
   
-  using proc::mobject::Session;
-  using proc::mobject::MObject;
-  using proc::mobject::session::Scope;
-  using proc::mobject::session::match_specificFork;
-  using proc::mobject::session::RBinding;
-  using proc::mobject::session::ForkID;
-  using proc::mobject::session::RFork;
-  using proc::mobject::session::Fork;
+  using steam::mobject::Session;
+  using steam::mobject::MObject;
+  using steam::mobject::session::Scope;
+  using steam::mobject::session::match_specificFork;
+  using steam::mobject::session::RBinding;
+  using steam::mobject::session::ForkID;
+  using steam::mobject::session::RFork;
+  using steam::mobject::session::Fork;
   
   using idi::StructTraits;
   

src/steam/asset/struct-scheme.hpp

@@ -104,7 +104,7 @@ namespace asset{
         static Symbol catFolder()  { return "pipes";}
         static Symbol idSymbol()   { return "pipe"; }
       };
-    template<> struct StructTraits<proc::StreamType>
+    template<> struct StructTraits<steam::StreamType>
       {
         static Symbol namePrefix() { return "type"; }
         static Symbol catFolder()  { return "stream-types";}

src/steam/asset/struct.cpp

@@ -54,7 +54,7 @@ using util::_Fmt;
 using lib::Symbol;
 using lib::query::normaliseID;
 using lumiera::query::QueryHandler;
-using proc::ConfigResolver;
+using steam::ConfigResolver;
 
 using util::contains;
 

src/steam/assetmanager.hpp

@@ -140,7 +140,7 @@ namespace asset {
 
 namespace proc_interface
   {
-  using proc::asset::AssetManager;
+  using steam::asset::AssetManager;
 }
 
 #endif