diff --git a/src/gui/widget/error-log-display.hpp b/src/gui/widget/error-log-display.hpp index 2d8361e46..19d2064f4 100644 --- a/src/gui/widget/error-log-display.hpp +++ b/src/gui/widget/error-log-display.hpp @@ -62,6 +62,7 @@ #include "gui/gtk-base.hpp" #include "gui/model/expander-revealer.hpp" #include "include/gui-notification-facade.h" +#include "lib/format-string.hpp" #include "lib/symbol.hpp" //#include "lib/util.hpp" @@ -73,6 +74,7 @@ namespace gui { namespace widget { + using util::_Fmt; using lib::Literal; using std::vector; @@ -143,10 +145,16 @@ namespace widget { model::Revealer reveal; + /** empty buffer and discard all error bookmarks */ void clearAll() { - UNIMPLEMENTED ("empty buffer and discard all error bookmarks"); + errorMarks_.clear(); + size_t lineCnt = textLog_.get_buffer()->get_line_count(); + string placeholder; + if (lineCnt > 0) + placeholder = _Fmt{_("───════ %d preceding lines removed ════───\n")} % lineCnt; + textLog_.get_buffer()->set_text (placeholder); // discard existing content } /** just add normal information message to buffer, diff --git a/src/include/gui-notification-facade.h b/src/include/gui-notification-facade.h index 2eca7f2bc..bb4970cfe 100644 --- a/src/include/gui-notification-facade.h +++ b/src/include/gui-notification-facade.h @@ -44,12 +44,16 @@ #ifdef __cplusplus /* ============== C++ Interface ================= */ #include "lib/depend.hpp" -#include "lib/diff/mutation-message.hpp" #include "lib/idi/entry-id.hpp" #include +namespace lib { + namespace diff { + class GenNode; + class MutationMessage; +} } namespace gui { using std::string; diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 9a14cf2a4..655a0034a 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -3358,7 +3358,7 @@ This treatment ensures each nested diff is consumed within a properly typed cont → this is the purpose of the {{{DataCap}}} within our [[generic node element|GenNode]] -
+
LayerSeparationInterface provided by the GUI.
 Access point for the lower layers to push information and state changes (asynchronously) to the GUI. Most operations within Lumiera are in fact initiated by the user through the GUI. In the course of such actions, the GUI uses the services of the lower layer and typically receives an immediate synchronous response to indicate the change was noted. Yet often, these operations may cause additional changes to happen asynchronously from the GUI's perspective. For example, an edit operation might trigger a re-build of the low-level model, which then detects an error. Any such consequences and notifications can be "cast" up into the UI, using the {{{NotificationService}}} described here.
 
@@ -3370,7 +3370,7 @@ The GuiNotificationFacade is installed as part of and managed by the ''UI Manage
 A dedicated ''activation state'' is necessary for this reason -- which within the implementation translates into a queuing and dispatching facility to reschedule any calls into the UI event thread ''asynchronously''.
 
 !Addressing of UI elements
-Most calls in this interface require to specify a receiver or target, in the form of an element ID. It is assumed the caller effectively just knows these ~IDs, typically because the same ~IDs are also used as element ~IDs for the corresponding session entities. And, to start with, the whole UI representation of the session was at some point generated by //population diff messages,// which used the same ~IDs to indicate the creation of the corresponding UI representation elements.
+Most calls in this interface require to specify a receiver or target, in the form of an element ID. It is assumed the caller effectively just knows these ~IDs, typically because the same ~IDs are also used as element ~IDs for the corresponding session entities. Even more so, since the whole UI representation of the session was at some point generated by //population diff messages,// which used the same ~IDs to indicate the creation of the corresponding UI representation elements.
@@ -9803,7 +9803,7 @@ For now, as of 6/10, we use specialised QueryResolver instances explicitly and d → QueryRegistration
-
+
Abstraction used in the Backbone of Lumiera's GTK User Interface
 The UI-Bus is a ''Mediator'' -- impersonating the role of the //Model// and the //Controler// in the [[MVC-Pattern|http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]] in common UI architecture.
 
@@ -9811,10 +9811,10 @@ The ~MVC-Pattern as such is fine, and probably the best we know for construction
 
 !!!rationale
 This way, we separate between immediate local control of UI state and the more global, generic [[interaction control|InteractionControl]] and [[command binding|GuiCommandBinding]].
-And we arrive at a backbone like structure, which can be wired, programmed and reasoned about while abstracting from the local concerns and the state management related to the UI toolkit set in use. Any element //of more than local relevance// -- be it a controller or be it a widget, representing some entity from the model -- will be attached to the UI-Bus by virtue of a ''bus terminal'', establishing a bi-directional connection. This enables any UI element to invoke commands and persist presentation state (by sending //"state mark" mesages//), and in turn this allows the session and engine core to "cast" state updates towards the UI, without precisely knowing where and how to reach the relevant presentation entities.
+And we arrive at a backbone like structure, which can be wired, programmed and reasoned about while abstracting from the local concerns and the state management related to the UI toolkit set in use. Any element //of more than local relevance// -- be it a controller or be it a widget, representing some entity from the model -- will be attached to the UI-Bus by virtue of a ''bus terminal'', establishing a bi-directional connection. This enables any UI element to invoke commands and persist presentation state (by sending //"state mark" mesages//), and in turn this allows the session and engine core to "cast" state updates towards the UI, without knowing in detail where and how to reach the relevant presentation entities.
 
 !!!topology
-The UI-Bus has a simple star shaped topology without hierarchical nesting and forwarding. It is not necessarily connected this way, since protocol and contracts do not assume any topology explicitly -- and the topology may be subject to change without further notice. We'll only assume there is a central hub somewhere in the bus, which maintains a routing table. Actually this hub represents the centre of the star and is known as ''Nexus''. Whenever an UI element connects to the bus, a routing entry is added, which allows the element to be directly invoked to receive messages. For that reason, every element connected this way must be at a fixed memory location.
+The UI-Bus has a simple star shaped topology without hierarchical nesting and forwarding. It is not necessarily connected this way, since protocol and contracts do not assume any topology explicitly -- and the topology may be subject to change without further notice. We'll only assume there is a central hub somewhere in the bus, which maintains a routing table. Actually this hub represents the centre of the star and is known as ''Nexus''. Whenever an UI element connects to the bus, a routing entry is added, which allows the element to be directly invoked to receive messages. For that reason, every element connected this way must stay put, at a fixed memory location.
 
 !!!degree of connectedness
 A connection point to the UI-Bus is called a ''Bus Terminal'' and implemented by class {{{BusTerm}}}. In fact, this class is the foundation of the ~UI-Bus network, with the Nexus being a specialisation. The //contract// involved with this connection requires the connected entity to respond to several messages, which effectively also means that this connected entity is a tangible UI-Element ({{{gui::model::Tangible}}} implements the necessary functions). But this pertains only to fully bidirectional bus connections, where the connected entity can receive messages addressed by it's ID. Beyond that, it is very much possible to operate a "free standing" bus terminal, which allows just to send "uplink" messages into the bus, without the need to add this terminal itself to the central routing table.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 7336c44ce..95c843a50 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -228,7 +228,7 @@
   
 
 
-
+
 
   
     
@@ -269,7 +269,7 @@
 
 
 
-
+
 
 
 
@@ -287,13 +287,58 @@
   
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      ...es könnte auch den Feedback des Users meinen
+    

+  
+
+
+
+
+
+
+
+
 
 
 
 
 
 
-
+
+
+
 
 
 
@@ -320,13 +365,11 @@
 
 
 
-
-
+
+
 
 
 
-
-
 
 
 
@@ -547,8 +590,7 @@
       Ein zu früher bzw. zu später Aufruf "fällt einfach hinten runter"
     

   
-
-
+
 
 
 
@@ -562,13 +604,12 @@
 
 
 
-
-
+
+
 
 
 
 
-
 
 
 
@@ -621,13 +662,14 @@
 
 
 
+
 
 
 
 
 
-
-
+
+
 
 
 
@@ -658,9 +700,11 @@
 
 
 
-
+
 
-
+
+
+
 
 
 
@@ -668,7 +712,7 @@
 
 
 
-
+
 
 
 
@@ -709,7 +753,7 @@
 
 
 
-
+
 
 
 
@@ -824,7 +868,7 @@
 
 
 
-
+
 
 
 
@@ -834,7 +878,7 @@
 
 
 
-
+
 
 
 
@@ -922,10 +966,10 @@
 
 
 
-
+
 
 
-
+
 
 
 
@@ -1400,8 +1444,7 @@
       mehr erscheint mir nicht sinnvoll; behandeln kann man solche Fehler ohnehin nicht.


     

   
-
-
+
 
 
 
@@ -1557,42 +1600,6 @@
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-    
-  
-  
-    

-      ...es könnte auch den Feedback des Users meinen
-    

-  
-
-
-
-
 
 
 
@@ -1804,7 +1811,7 @@
 
 
 
-
+
 
   
     
@@ -1818,7 +1825,10 @@
     

   
 
-
+
+
+
+
 
 
 
@@ -1847,7 +1857,7 @@
 
 
 
-
+
 
 
 
@@ -2037,8 +2047,25 @@
 
 
 
-
-
+
+
+
+
+
+  
+    
+  
+  
+    

+      ...um den Umstand zu dokumentieren,
+    

+    

+      daß hier ## Zeilen gelöscht wurden
+    

+  
+
+
+
 
 
 
@@ -2684,9 +2711,9 @@
 
 
 
-
-
-
+
+
+
 
 
 
@@ -2771,7 +2798,7 @@
 
 
 
-
+
 
 
 
@@ -2865,7 +2892,7 @@
 
 
 
-
+
 
 
 
@@ -2884,7 +2911,7 @@
 
 
 
-
+
 
 
 
@@ -3022,7 +3049,7 @@
 
 
 
-
+