diff --git a/doc/technical/code/gtk/startup.txt b/doc/technical/code/gtk/startup.txt index 66b65c23f..713be5d33 100644 --- a/doc/technical/code/gtk/startup.txt +++ b/doc/technical/code/gtk/startup.txt @@ -115,6 +115,10 @@ signal is emitted _shortly before_ entering the event loop, and not from within A better alternative is to rely on the `Glib::signal_idle()` rsp. `Glib::signal_timeout()`. Both allow to invoke a slot only once, and both ensure the invocation really happens from within the event loop. +footnote:[Verified as of 8/2018: uses `g_main_context_default()`, which creates the default context +on demand. This is also the default context _pulled_ when running the event loop. So indeed we're +able to attach an ``event source'' (i.e. an action or closure) even before the loop is running. +Use `Glib::PRIORITY_LOW` to schedule after any (re)drawing activities.] SigC++ trackable ~~~~~~~~~~~~~~~~ diff --git a/src/gui/interact/interaction-director.cpp b/src/gui/interact/interaction-director.cpp index 23bbd79ca..9707c1775 100644 --- a/src/gui/interact/interaction-director.cpp +++ b/src/gui/interact/interaction-director.cpp @@ -86,8 +86,7 @@ namespace interact { * @param globals wiring to the circle of top-level UI managers (including ourselves) * @warning this ctor is performed within the UI thread, yet _prior_ to entering the GTK event loop. * For this reason, all initialisation performed here must be wiring-only; any tasks requiring an - * actually operative UI need to be scheduled, by means of the NotificationService. - * @todo 7/2018 STOP no, can't be the NotificationService. ////////////////////////////////////////////TICKET #1151 : Need a new dedicated service in UiManager + * actually operative UI will be _scheduled,_ to run later when the UI is fully operative. */ InteractionDirector::InteractionDirector (GlobalCtx& globals) : model::Controller(session::Root::getID(), globals.uiBus_.getAccessPoint()) @@ -100,7 +99,17 @@ namespace interact { , assets_{new AssetController{session::Root::getAssetID(), this->uiBus_}} , timelines_{} { - + Glib::signal_timeout() + .connect_once (sigc::mem_fun(*this, &InteractionDirector::populateContent_afterStart) + ,DELAY_AFTER_GUI_START_in_ms + ,Glib::PRIORITY_LOW); // after all initial drawing tasks + } + + + void + InteractionDirector::populateContent_afterStart() + { + UNIMPLEMENTED ("issue content population request as command into the session"); } diff --git a/src/gui/interact/interaction-director.hpp b/src/gui/interact/interaction-director.hpp index 8a8c67aa0..d6d22d076 100644 --- a/src/gui/interact/interaction-director.hpp +++ b/src/gui/interact/interaction-director.hpp @@ -121,12 +121,18 @@ namespace interact { Assets assets_; Timelines timelines_; + /** set up a binding to allow some top-level UI state * to be treated as part of the session model - * @see tree-mutator.hpp + * @see tree-mutator.hpp */ void buildMutator (lib::diff::TreeMutator::Handle) override; + /** ask Session to push up structures for presentation */ + void populateContent_afterStart(); + + static constexpr auto DELAY_AFTER_GUI_START_in_ms = 100; + public: InteractionDirector (ctrl::GlobalCtx&); ~InteractionDirector (); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index bbe634ec5..44dd1a5e5 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -3058,7 +3058,7 @@ The consequence is that both sides, "the core" and "the UI" Rather, the core sends ''diff messages'' up to the UI, indicating how it sees this virtual structure to be changing. The UI reflects these changes into //its own understanding and representation,// that is here a structure of display widgets. When the user interacts with these structures of the presentation layer, ''command messages'' are generated, using the element ~IDs to designate the arguments of the intended operation. This again causes reaction and change in the core, which is reflected back in the form of further diff messages. (→ GuiCommandCycle) -
//install a listener into the session to cause sending of population diff messages.//
The Lumiera application is not structured as an UI with internal functionality dangling below. Rather, the architecture calls for several self-contained subsystems, where all of the actual "application content" is modelled within the [[Session]] subsystem. The UI implements the //mechanics of user interaction// -- yet as far as content is concerned, it plays a passive role. Within the UI-Layer, there is a hierarchy of presentation entities, to mirror the structure of the session contents. These entities are built step by step, in reception of //population diff messages// sent upwards from the session.
@@ -3071,6 +3071,7 @@ And since we are talking about a generic facility, the framework of content popu
The general plan to trigger content population thus boils down to
* have the InteractionDirector inject the population trigger with the help of {{{Glib::signal_timeout()}}}
+* which will activate with a slight delay (100ms) after UI start, and after primary drawing activities ceases
* the trigger itself issues a command towards the session
* execution of aforementioned command activates sending of population / diff messages
* on shutdown of the top-level, send the corresponding deactivation command
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 20f435e9a..64d37c531 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -2,8 +2,8 @@