diff --git a/doc/technical/gui/GuiConnect.txt b/doc/technical/gui/GuiConnect.txt new file mode 100644 index 000000000..84458a8fc --- /dev/null +++ b/doc/technical/gui/GuiConnect.txt @@ -0,0 +1,80 @@ +GUI Connection +============== + +The Lumiera application is built from several segregated software layers, and the user interface, the GUI-Layer is +optional and loaded as a plug-in. This deliberate design decision has far reaching consequences in all parts of the +application: Anything of relevance for editing or rendering need to be _represented explicitly_ within a model, distinct +and abstracted from the presentation for the user. For example, many media handling applications let you ``snap'' some +entity to a ``grid'', which happens conveniently during a given user interaction, just resulting in a new position for +the element at hand. In Lumiera, we can not follow this obvious and pragmatic approach -- rather, both the time grid +and the fact an object as been attached and aligned to such a grid need to be represented in the session model proper, +resulting in a `Placement`. More specifically, we can not derive behaviour of such an object from circumstantial +state data present in the UI. Rather, we need to compute the new position based on rules within the session. +And then we need to _communicate_ the result back into the UI -- if and when an UI is present to reflect that change. + +So instead of having a _»Controller«_ mediate the interplay of a _»Model«_ and the _»View«_ presentation, we end up +with a complete _communication cycle,_ where messages are sent in both directions, and _sent asynchronously._ + +Principles of UI / Core interaction +----------------------------------- +By all means, we avoid a common shared data structure as foundation for interaction. Such a _data centric_ approach +may lean towards two extremes, both of which are problematic. A _naively written application_ starts with building +the user interface and hinges any further internal structures directly below. For a tiny application, which is +basically ``just some interface controls'', such an approach might be adequate -- yet maintaining the ``code behind'' +the control surface quickly becomes a nightmare. We may avoid those immediate problems by settling down on a strictly +codified central _core data model._ And while this shift towards the other extreme of a data centric architecture +indeed resolves the immediately pressing maintenance problems, this settlement comes with an substantial price tag. +Since interface and core functionality are now torn apart, the code conducting even the simplest interaction is +scattered over various parts of the system, and thus everything need to be very well defined and documented. +Such a system becomes rigid as soon as it is built. And additionally it tends to suffer from structure duplication +and multiplication, since cross interactions involving several parts of the core and the surface tend to be had +to express: Interaction state need to be materialised into the core data, to allow other, distinct parts of the +interface to collaborate. + +We may escape from that dichotomy when we cease to _rely on data as the fundamental substrate of our system._ +To collaborate, both parts still need to share a structure, yet it suffices for this structure to be a _common +understanding:_ both the UI-Layer and the Proc-Layer need to share a common understanding how the parts of a editing +session can be arranged. Yet they do not need to share a _common data representation_ of the session. + +The consequence is that both sides, ``the core'' and ``the UI'' remain autonomous within their realm. For some concerns, namely _the core concerns,_ that is editing, arranging, processing, the core is in charge and has absolute authority. +On the other hand, when it comes to user interaction, especially the _mechanics and materiality of interaction,_ the UI +is the authority; it is free to decide about what is exposed and in which way. Yet the common structural understanding +is never fully, totally cast in concrete data structures. + +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,_ which is here a structure of display +widgets. When the user interacts with these structures of the presentation layer, *action command messages* are generated, +using the element-IDs to designate the arguments of the intended operation. Acting on these messages again causes reaction and change in the core, which is reflected back in the form of further diff messages. + +Anatomy of the Proc/GUI interface +--------------------------------- +- the `GuiFacade` is used as a general lifecycle facade to start up the GUI and to set up the »Layer Separation + Interfaces«. The `GuiFacade` is implemented by a class _in Proc-Layer_ and loads the Lumiera GTK-UI as a plug-in. +- once the UI is running, it exposes the `GuiNotificationFacade`, to allow pushing state and structure updates up into + the user interface. +- in the opposite direction, for initiating actions from the UI, the Session Subsystem opens the `SessionCommandFacade`, + which can be considered __ ``the'' public session interface.__ + +Both these primary interfaces operate *message based.* As immediate consequence, these interfaces are comparatively +narrow, and interactions can easily be serialised, enqueued and dispatched. On the Proc-Layer side, the `ProcDispatcher` +coordinates command execution and the _Builder run_ to derive the consequences of those session command invocations. +And within the UI, the GTK-Event loop runs likewise single threaded, and the Notification facade automatically +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`). +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 +element is actually attached within the widget tree of the user interface. Even diff messages are dispatched over +the UI-Bus; it is up to the receiving tangible element to decide about the meaning of such a diff message, and +how to reshape its internal widget state to reflect that change. + +When it comes to the more elaborate parts of the model and the UI -- especially for the timeline -- those tangible +elements need not be widgets by themselves. Rather, they can be local presentation controllers, often also referred +to as *Presenter*. These manage and control a selection of slave widgets to form the visual presentation of the +corresponding session entity. For example, a `ClipPresenter` injects one or a conglomerate of several widgets +into the track canvas, depending on the current zoom level and the display state of the clip (collapsed, expanded, +abridged display). + diff --git a/doc/technical/gui/guiTheme.txt b/doc/technical/gui/GuiTheme.txt similarity index 84% rename from doc/technical/gui/guiTheme.txt rename to doc/technical/gui/GuiTheme.txt index f28327e57..2fa13d845 100644 --- a/doc/technical/gui/guiTheme.txt +++ b/doc/technical/gui/GuiTheme.txt @@ -17,7 +17,9 @@ introduce additional engine specific styles and settings. GTK-3 supports the powerful 'cascading' and 'contextual selectors' from CSS. Thus the nesting of elements in the GUI forms the base for creating styling rules. Hereby, widget class names translate into ``tag'' names -in the CSS selectors. Widgets may also expose CSS classes for styling -- the standard widgets define a generic set +in the CSS selectors.footnote:[The ``tag'' name is the widget's class name without the `Gtk::` prefix, and transformed +into all lower caps, single word, no underscores. E.g. `Gtk::TextView` -> `textview`] +Widgets may also expose CSS classes for styling -- the standard widgets define a generic set of https://developer.gnome.org/gtk3/3.4/GtkStyleContext.html#gtkstylecontext-classes[predefined CSS style classes], which can be used to establish the foundation for theming. Obviously it is preferable to keep styling rules as concise, generic and systematic as possible; yet we may still refer to individual gui elements by name (`#ID`) though. @@ -53,6 +55,15 @@ A good recommendation is really to ``probe'' settings by changing them temporari (e.g. `background-color: red`). It is just too easy to learn wrong techniques based on false conclusions. +the GTK+ inspector +~~~~~~~~~~~~~~~~~~ +An essential tool when working with styles and Gtk widgets in general is the +https://wiki.gnome.org/Projects/GTK%2B/Inspector[GTK+ inspector], which is part of the standard GTK distribution. +It allows to inspect all GTK objects with their properties, and to see the actual tree of CSS nodes and the +corresponding selectors. You can even add a style class or state flag (like ``hover'') dynamically, and you +may add style rules and verify the effect on the application immediately. To use this ispector, launch the +application like `GTK_DEBUG=interactive target/lumiera` + binary themes ~~~~~~~~~~~~~ diff --git a/src/gui/ctrl/notification-hub.hpp b/src/gui/ctrl/notification-hub.hpp index ec027d41f..225bdc6da 100644 --- a/src/gui/ctrl/notification-hub.hpp +++ b/src/gui/ctrl/notification-hub.hpp @@ -41,12 +41,11 @@ ** The actual widget for information display is prepared, but it is actually allocated when ** the need for information display arises. Which means, the user may close this display ** widget, thereby discarding its current information content -- but when the next notification - ** needs to be shown, the controller will ensure to allocate an appropriate widget again. Moreover, - ** the widget can be _expanded_ or _collapsed_, without affecting its content. + ** needs to be shown, the controller will ensure to allocate an appropriate widget again. + ** Moreover, the widget can be _expanded_ or _collapsed_, without affecting its content. ** - information messages are just added to the buffer without much ado. No attempt is made ** to reveal or expand the widget (but if necessary, a new widget is allocated) - ** - error messages also set an error marker state (*TODO* reflect this in the presentation), - ** and they cause the display widget to be expanded + ** - error messages also set an error marker state, and cause expansion of the display widget. ** - the error state can be _cleared_, which also demotes all error messages to mere information. ** - information content can also be _cleared_, which removes all mere information messages, ** while retaining the error entries. @@ -91,7 +90,7 @@ namespace ctrl { { - /** content population and manipulation via UI-Bus */ + /** population and manipulation of persistent content via UI-Bus */ void buildMutator (lib::diff::TreeMutator::Handle buffer) override { diff --git a/src/gui/demo-gui-roundtrip.cpp b/src/gui/demo-gui-roundtrip.cpp deleted file mode 100644 index f22834533..000000000 --- a/src/gui/demo-gui-roundtrip.cpp +++ /dev/null @@ -1,112 +0,0 @@ -/* - DemoGuiRoundtrip - placeholder to further progress of the GUI-Session connection - - 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 demo-gui-roundtrip.cpp - ** Dummy and scaffolding to help development of the UI - Session connection. - ** The Goal is to establish a full messaging round-trip between UI and Proc-Layer - ** - a menu entry - ** - which issues a Proc-Command - ** - which in turn accesses the Notification-facade - ** - and sends a "mark" message towards some UI demo widget - ** - which in turn displays the mark text - ** - ** @todo WIP as of 8/2017 ////////////////////////////////////////////////////////////////////////TICKET #1099 - ** - ** @see CallQueue_test - ** @see notification-service.hpp - ** - */ - -#include "gui/gtk-base.hpp" - -#include "lib/error.hpp" -#include "lib/depend.hpp" -#include "gui/ui-bus.hpp" -#include "gui/ctrl/ui-manager.hpp" -#include "lib/nocopy.hpp" - -#include - - - -//using lumiera::error::LUMIERA_ERROR_STATE; - -using std::string; - - -namespace gui { - - namespace { // implementation details - -//using util::isnil; - using std::string; - - } // (End) impl details - - - - - - /** - * Quick-n-dirty hack to establish a prototypic connection between Application Core and UI... - * - * @todo be commendable - * @todo don't misbehave - * - * @see SomeSystem - * @see CallQueue_test - */ - class DemoGuiRoundtrip - : util::NonCopyable - { - string nothing_; - - DemoGuiRoundtrip(); - ~DemoGuiRoundtrip(); - - friend class lib::DependencyFactory; - - public: - /** access point to set up the scaffolding. - * @internal this is a development helper and will be remoulded all the time. - */ - static lib::Depend instance; - - - /* == X interface for == */ - - /* == Adapter interface for == */ - -#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1099 - void setSolution (string const& solution = "") - { - UNIMPLEMENTED ("tbw"); - if (isDeaf()) - this->transmogrify (solution); - } -#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1099 - }; - - - -} // namespace gui diff --git a/src/gui/dialog/test-control.hpp b/src/gui/dialog/test-control.hpp index 4a2796407..8d8b04e77 100644 --- a/src/gui/dialog/test-control.hpp +++ b/src/gui/dialog/test-control.hpp @@ -29,7 +29,7 @@ ** helper routines to be hooked up easily within the UI. Actions launched from here ** perform within the same environment as regular user interactions. ** - ** @todo as of 9/2018, this is a first rough draft, relevant for #1099 ////////////////////////////TICKET #1074 gradually augment the self-diagnostics controls in the UI + ** @todo as of 9/2018, this is a first rough draft, relevant for #1099 ////////////////////////////TICKET #1140 gradually augment the self-diagnostics controls in the UI ** @todo this header also features a design draft how to simplify building notebook widgets. ** Which could be polished and moved into a separate utility header eventually. */ diff --git a/src/gui/interact/interaction-director.cpp b/src/gui/interact/interaction-director.cpp index 3b63432e0..0c272b6e1 100644 --- a/src/gui/interact/interaction-director.cpp +++ b/src/gui/interact/interaction-director.cpp @@ -109,11 +109,6 @@ namespace interact { void InteractionDirector::populateContent_afterStart() { - ///////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1099 trigger creation of the UI notification display here - //// TODO : this clearly is a preliminary solution. Later it might be possible, - //// : to create the notification display on demand. But right now (8/2018) - //// : we need a GuiComponentView with predictable ID instructed to exist "somewhere" - //// invoke (cmd::test_meta_activateContentDiff); ////////////////////////////////////////////TICKET #211 prefix test_ bypasses logging and immediately executes for now (2018) } diff --git a/src/gui/model/flash-deco.hpp b/src/gui/model/flash-deco.hpp index dbd5d290c..15889a76c 100644 --- a/src/gui/model/flash-deco.hpp +++ b/src/gui/model/flash-deco.hpp @@ -24,7 +24,7 @@ /** @file flash-deco.hpp ** Decorator to add the ability to display a visual flash action to a GTK widget. ** The protocol for operating UI elements connected to the [UI-Bus](\ref ui-bus.hpp) includes - ** a message to make the receiving widget flash for a short time, to mandate the users attention. + ** a message to make the receiving widget flash for a short time, to mandate the user's attention. ** The visual change itself is effected by adding a CSS class, while adding a timeout callback ** to revert to normal display after a short timespan. In itself, this modification sequence ** is entirely generic, and can thus be added by decorating the widget to affect; moreover, @@ -44,13 +44,9 @@ #include "gui/gtk-base.hpp" #include "gui/style-scheme.hpp" -//#include - namespace gui { namespace model { - -// using std::move; /** @@ -90,6 +86,5 @@ namespace model { }; - }} // namespace gui::model #endif /*GUI_MODEL_FLASH_DECO_H*/ diff --git a/src/gui/panel/infobox-panel.cpp b/src/gui/panel/infobox-panel.cpp index 8e4aa66dd..24f1bcd5c 100644 --- a/src/gui/panel/infobox-panel.cpp +++ b/src/gui/panel/infobox-panel.cpp @@ -79,8 +79,8 @@ namespace panel{ // after the UI is actually mapped to screen. Glib::signal_idle() .connect_once ( sigc::bind( - sigc::mem_fun(*this, &InfoBoxPanel::reflect_LogErrorState), false - )); + sigc::mem_fun (*this, &InfoBoxPanel::reflect_LogErrorState), false) + ); } @@ -98,7 +98,7 @@ namespace panel{ /** on demand allocate display of information / error log - * @note we assume it stays alive forever, once allocated + * @note we assume it stays alive until the panel itself is closed. * @remark the ErrorLogDisplay widget exposes a \ref Expander functor, * which is wired here with the Gtk::Expander container holding the Log. * This setup allows to trigger the expand/collapse functionality and @@ -113,7 +113,7 @@ namespace panel{ theLog_.reset (new ErrorLogDisplay{}); logExpander_.set_expanded (false); logExpander_.add (*theLog_); - theLog_->expand = model::Expander{[&]() { return logExpander_.get_expanded(); } + theLog_->expand = model::Expander{[&]() -> bool { return logExpander_.get_expanded(); } ,[&](bool yes) { logExpander_.set_expanded (yes); } }; theLog_->reveal = model::Revealer{[&]() { Panel::show(true); @@ -135,7 +135,6 @@ namespace panel{ { buttonClearErr_.set_visible (isError); buttonClearInfo_.set_visible (isError); - INFO (gui, "Error = %d", isError); } diff --git a/src/gui/panel/infobox-panel.hpp b/src/gui/panel/infobox-panel.hpp index b7e0907c5..4ef8c1b0f 100644 --- a/src/gui/panel/infobox-panel.hpp +++ b/src/gui/panel/infobox-panel.hpp @@ -26,7 +26,7 @@ ** Such an »Info Box« typically exposes detail settings from some other component ** currently selected, and allows to access those in a non modal fashion. ** - ** @todo as of 8/2017 this is (ab)used as space for UI / Proc-Layer integration experiments + ** @todo as of 10/2017 this is used as space to host the information and error log */ @@ -53,7 +53,8 @@ namespace panel{ * @param PanelManager The owner panel manager widget. * @param DockItem The GdlDockItem that will host this panel. * - * @todo as of 8/2017 this is placeholder code for UI experiments... + * @todo just used as place for the error log as of 10/2017. + * More to come... */ InfoBoxPanel (workspace::PanelManager&, Gdl::DockItem&); diff --git a/src/gui/style-scheme.cpp b/src/gui/style-scheme.cpp index c0a9212eb..1dd8cf8c6 100644 --- a/src/gui/style-scheme.cpp +++ b/src/gui/style-scheme.cpp @@ -36,7 +36,10 @@ namespace gui { const Literal TAG_ERROR{"ERROR"}; ////////////////////////////////////////////////////////////TICKET #1168 : find a way to manage style of custom extended UI elements const Literal TAG_WARN{"WARN"}; - cuString CSS_CLASS_FLASH{"indication_flash"}; ///< CSS class added temporarily to make a widget "flash" in response to the corresponding UI-Bus message + /** CSS class added temporarily to make a widget "flash" + * in response to the corresponding UI-Bus message + * @see flash-deco.hpp */ + cuString CSS_CLASS_FLASH{"indication_flash"}; const uint STYLE_FLASH_DURATION_in_ms = 1100; diff --git a/src/gui/widget/error-log-display.hpp b/src/gui/widget/error-log-display.hpp index 358c9e1ea..9e75b0977 100644 --- a/src/gui/widget/error-log-display.hpp +++ b/src/gui/widget/error-log-display.hpp @@ -34,9 +34,9 @@ ** to an ErrorLogDisplay found within the InfoBoxPanel, using it as holder for ** information and error messages pushed into the GUI. For that reason, it is ** important really _to destroy_ the ErrorLogDisplay, when it is taken out of - ** service. Since ErrorLogDisplay inherits from `sigc::tangible`, it is + ** service. Since ErrorLogDisplay inherits from `sigc::trackable`, it is ** automatically detached from the WLink implementing this cross-attachment, - ** when actually the dtor is called. + ** but only when _actually the dtor is called._ ** @note this is a special convention; usually it is sufficient just to hide() ** a GTK widget, because it is then left alone by the event handling and ** automatically cleaned up at shutdown. Moreover, if you ` remove()` a @@ -51,7 +51,7 @@ ** used as receiver by the GuiNotificationService. ** @todo WIP-WIP and in 9/2018 this draft gradually shifts towards a prototype ** how to deal with custom configured widget behaviour, and how to integrate - ** with our GUI framework /////////////////////////////////////////////////////////////TICKET #1099 : build a prototype/dummy for UI <-> Proc integration + ** with our GUI framework (#1099) ** */ @@ -149,8 +149,8 @@ namespace widget { // the vertical scrollbar will always be necessary.... set_policy (Gtk::POLICY_AUTOMATIC, Gtk::POLICY_ALWAYS); - this->add (textLog_); textLog_.set_editable (false); + this->add (textLog_); populateStandardTextTags (textLog_.get_buffer()->get_tag_table()); } @@ -163,7 +163,7 @@ namespace widget { void clearAll() { - bool shallNotify = not errorMarks_.empty(); + bool shallNotify = this->isError(); errorMarks_.clear(); size_t lineCnt = max (0, textLog_.get_buffer()->get_line_count() - 1); @@ -202,10 +202,10 @@ namespace widget { void addError (string text) { - bool shallNotify = errorMarks_.empty(); + bool shallNotify = not this->isError(); errorMarks_.emplace_back( - addEntry ("ERROR: "+text, TAG_ERROR)); + addEntry ("ERROR: "+text, TAG_ERROR)); if (not expand.isExpanded()) expand (true); @@ -226,7 +226,7 @@ namespace widget { for (Entry& entry : errorMarks_) { newBuff->insert (newBuff->end(), "\n"); - auto pos = newBuff->end(); + auto pos = newBuff->end(); --pos; newMarks.emplace_back( make_pair ( @@ -255,7 +255,7 @@ namespace widget { void turnError_into_InfoMsg() { - bool shallNotify = not errorMarks_.empty(); + if (not isError()) return; auto buff = textLog_.get_buffer(); for (Entry& entry : errorMarks_) @@ -264,17 +264,15 @@ namespace widget { auto end = entry.second->get_iter(); buff->remove_tag_by_name(uString{TAG_ERROR}, begin,end); - buff->apply_tag_by_name (uString{TAG_WARN}, begin,end); + buff->apply_tag_by_name (uString{TAG_WARN}, begin,end); } errorMarks_.clear(); - - if (shallNotify) - errorChangedSignal_.emit (false); + errorChangedSignal_.emit (false); } /** temporarily change display style to prompt for attention; - * set callback-timeout to return to normal state. + * set callback-timeout for return to normal state. * @see \ref gui::CSS_CLASS_FLASH */ void @@ -308,7 +306,7 @@ namespace widget { * @remark an entry is content sans the following line break, which is appended automatically. * We inject the content _between_ two marks, which will adjust when content is altered. * @remark According to the [API doc], `TextView::scroll_to(iter)` is not reliable; preferably - * we should use a text mark and set that text mark to the [insert position][insert-mark]. + * we should use a text mark, which could e.g. be the [insert position][insert-mark]. * The handling of marks and tags is described in the [GTKmm tutorial]. * @warning Each entry creates a new pair of marks. Not sure about the impact on performance... * @@ -324,7 +322,7 @@ namespace widget { auto pos = buff->end(); --pos; auto begin = buff->create_mark (pos, true); // "left gravity" : stays to the left of inserted text - auto after = buff->create_mark (pos, false);// "right gravity": sticks right behind the inserted text + auto after = buff->create_mark (pos, false); // "right gravity": sticks right behind the inserted text if (markupTagName) buff->insert_with_tag(pos, text, cuString{markupTagName}); else diff --git a/src/proc/cmd/meta-cmd.cpp b/src/proc/cmd/meta-cmd.cpp index 69f78dc93..5eeb7fcbd 100644 --- a/src/proc/cmd/meta-cmd.cpp +++ b/src/proc/cmd/meta-cmd.cpp @@ -39,10 +39,10 @@ #include "proc/control/command-def.hpp" //#include "proc/mobject/session.hpp" #include "include/gui-notification-facade.h" -#include "gui/interact/wizard.hpp" //////////////////////////////////////////////////////////////TICKET #1099 : include needed temporarily +#include "gui/interact/wizard.hpp" //////////////////////////////////////////////////////////////TICKET #1140 : include needed temporarily #include "lib/diff/gen-node.hpp" #include "lib/idi/entry-id.hpp" -#include "lib/format-string.hpp" //////////////////////////////////////////////////////////////TICKET #1099 : include needed temporarily +#include "lib/format-string.hpp" //////////////////////////////////////////////////////////////TICKET #1140 : include needed temporarily //#include "lib/symbol.hpp" #include "lib/util.hpp" @@ -57,7 +57,7 @@ using gui::NotifyLevel; using gui::GuiNotification; using lib::diff::GenNode; //using util::cStr; -using util::_Fmt; //////////////////////////////////////////////////////////////TICKET #1099 : include needed temporarily +using util::_Fmt; //////////////////////////////////////////////////////////////TICKET #1140 : include needed temporarily using util::isYes; using std::string; @@ -144,7 +144,7 @@ COMMAND_DEFINITION (meta_deactivateContentDiff) /* ===== Demo and Development ===== */ /** DemoGuiRoundtrip: push a notification info message back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1099 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication */ COMMAND_DEFINITION (test_meta_displayInfo) { @@ -164,7 +164,7 @@ COMMAND_DEFINITION (test_meta_displayInfo) /** DemoGuiRoundtrip: send a `markError` message back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1099 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication */ COMMAND_DEFINITION (test_meta_markError) { @@ -185,7 +185,7 @@ COMMAND_DEFINITION (test_meta_markError) /** DemoGuiRoundtrip: send a `markNote` message back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1099 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication */ COMMAND_DEFINITION (test_meta_markNote) { @@ -206,7 +206,7 @@ COMMAND_DEFINITION (test_meta_markNote) /** DemoGuiRoundtrip: send a generic `mark` message with given _action ID_ back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1099 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication */ COMMAND_DEFINITION (test_meta_markAction) { diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 723417fae..7f9f9ecc6 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -38,23 +38,45 @@ - - - + + + - - + + - - + + + + + + + + + + + + + +

+ TODO: Infos zusammentragen und dokumentieren +

+ + + + + + + + @@ -66,9 +88,10 @@ - - + + + @@ -216,7 +239,7 @@ - + @@ -228,6 +251,7 @@ + @@ -665,7 +689,7 @@ - + @@ -935,7 +959,7 @@ - + @@ -943,8 +967,9 @@ - + + @@ -996,8 +1021,10 @@ - - + + + + @@ -1006,12 +1033,12 @@ - + - + - + @@ -1035,9 +1062,9 @@ - + - + @@ -1270,7 +1297,7 @@ - + @@ -1281,7 +1308,7 @@ - + @@ -1363,7 +1390,7 @@ - + @@ -1373,7 +1400,7 @@ - + @@ -1384,7 +1411,7 @@ - + @@ -1450,7 +1477,7 @@ - + @@ -1465,7 +1492,7 @@ - + @@ -1534,14 +1561,14 @@ - + - + - - + + @@ -1554,11 +1581,12 @@ - - + + - + + @@ -1570,7 +1598,7 @@ - + @@ -1592,11 +1620,11 @@ - + - + @@ -1767,13 +1795,7 @@ - - - - - - - + @@ -2514,8 +2536,8 @@ - - + + @@ -2591,7 +2613,7 @@ - + @@ -2832,15 +2854,15 @@

- + - + - - + + @@ -3023,7 +3045,7 @@ - + @@ -3808,7 +3830,7 @@ - + @@ -3816,24 +3838,24 @@ - - + + - - + + - - + + - - + + - - + + - + - + @@ -3861,8 +3883,8 @@ - - + + @@ -3874,8 +3896,22 @@ - - + + + + + + + + + +

+ #1174 UI self diagnostics window +

+ + + + @@ -3883,7 +3919,7 @@ - + @@ -3897,6 +3933,7 @@

+ @@ -3917,7 +3954,7 @@ - + @@ -3978,7 +4015,7 @@ - + @@ -4009,7 +4046,7 @@ - + @@ -4025,7 +4062,7 @@ - + @@ -4112,7 +4149,7 @@ - + @@ -4180,7 +4217,7 @@ - + @@ -4194,7 +4231,7 @@ - + @@ -4247,7 +4284,7 @@ - + @@ -4345,7 +4382,7 @@ - + @@ -4458,7 +4495,7 @@ - + @@ -4541,7 +4578,7 @@ - + @@ -4662,7 +4699,7 @@ - + @@ -4752,9 +4789,9 @@ - + - + @@ -4778,9 +4815,9 @@ - + - + @@ -4792,7 +4829,7 @@ - + @@ -4868,7 +4905,7 @@ - + @@ -4905,7 +4942,7 @@ - + @@ -4933,7 +4970,7 @@ - + @@ -4970,7 +5007,7 @@ - + @@ -5000,7 +5037,7 @@ - + @@ -5039,7 +5076,7 @@ - + @@ -5124,7 +5161,8 @@ - + + @@ -5138,6 +5176,10 @@ + + + + @@ -5674,9 +5716,9 @@ - + - + @@ -18464,9 +18506,10 @@ - + - + + @@ -18479,62 +18522,43 @@ - + + - - - - - - - - - - -

- ...wird zwar vom Skript ausgelesen, -

-

- aber nicht weiterverwendet. -

-

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

- - - - - - - - + + + - - - - + + + + - - + + - - + + + + + - - + + - + + @@ -18794,9 +18818,9 @@ - + - + @@ -18937,9 +18961,12 @@ - + - + + + + @@ -26899,7 +26926,7 @@ - + @@ -26915,7 +26942,7 @@ - + @@ -26934,7 +26961,7 @@ - + @@ -26946,7 +26973,7 @@ - + @@ -27040,7 +27067,7 @@ - + @@ -27075,7 +27102,7 @@ - + @@ -27092,7 +27119,7 @@ - + @@ -27106,7 +27133,7 @@ - + @@ -40547,6 +40574,38 @@ + + + + + + + + + + + +

+ ...wird zwar vom Skript ausgelesen, +

+

+ aber nicht weiterverwendet. +

+

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

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