benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

After a looong break.... start reading code

Browse source 
wtf was I doing before that damn release and packaing business
This commit is contained in:
Fischlurch 2015-11-21 03:39:07 +01:00
parent 60b6267eac
commit 6a0b9980e3
4 changed files with 145 additions and 40 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

77
src/gui/ctrl/bus-term.hpp Normal file
View file

@ -0,0 +1,77 @@
/*
BUS-TERM.hpp - connection point for UI elements to the UI-Bus
Copyright (C) Lumiera.org
2015, Hermann Vosseler <Ichthyostega@web.de>
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 bus-term.hpp
** Attachment point to the UI-Bos.
** Every gui::model::Tangible holds a BusTerm, which is linked
** to the Tangible's identity, and serves to relay interface actions
** towards the Proc-Layer. Moreover, the BusTerm is the service point
** to receive structural change messages.
**
** @todo as of 11/2015 this is complete WIP-WIP-WIP
**
** @see ////TODO_test usage example
**
*/
#ifndef GUI_CTRL_BUS_TERM_H_
#define GUI_CTRL_BUS_TERM_H_
#include "lib/error.hpp"
//#include "lib/symbol.hpp"
//#include "lib/util.hpp"
#include <boost/noncopyable.hpp>
#include <string>
namespace gui {
namespace ctrl{
// using lib::HashVal;
// using util::isnil;
using std::string;
/**
* @todo write type comment...
*/
class BusTerm
: boost::noncopyable
{
string nothing_;
public:
BusTerm();
~BusTerm();
protected:
string mayday () const;
};
}} // namespace gui::ctrl
#endif /*GUI_CTRL_BUS_TERM_H_*/

22
src/lib/meta/duck-detector.hpp
View file

@ -23,16 +23,16 @@
/** @file duck-detector.hpp
** Metaprogramming helpers to check for specific properties of a type in question.
** Building upon the "SFINE" principle, it is possible to create \em metafunction templates,
** which answer some questions about a given type at compile time. A lot of generic flavours of
** this kind can be found in the boost-type-trait library (part of std::tr1). At times though,
** you want to ask more specific questions, like e.g. "does this type provide an operation \c quack() "?
** Building upon the "SFINAE" principle, it is possible to create \em metafunction templates,
** which answer some questions about a given type at compile time. A lot of generic predicates of
** this kind can be found in the \c <type_traits> library (standard since C++11). At times though,
** you want to ask more specific questions, like e.g. "does this type provide an operation quack() "?
** Because, if we can get a \c bool answer to such a question <i>at compile time,</i> we can use
** \c boost::enable_if to pick a special implementation based on the test result. Together, these
** techniques allow to adopt a duck-typed programming style, where an arbitrary object is allowed
** to enter a given API function, provided this object supports some specific operations.
**
** While C++ certainly isn't a dynamic language and doesn't provide any kind of run time introspection,
** While C++ certainly isn't a dynamic language and does not provide any kind of run time introspection,
** doing such check-and branch at compile time allows even to combine such a flexible approach with
** static type safety, which is compelling. (The downside is the danger of code bloat, as is with all
** template based techniques).
@ -42,16 +42,16 @@
** Most of these trait templates rely on a creative use of function overloading. The C++ standard
** requires the compiler <i>silently to drop</i> any candidate of overload resolution which has
** gotten an invalid function signature as a result of instantiating a template (type). This allows
** us to set up kind of a "trap" for the compiler: we present two overloaded candidate functions
** us to set up kind of a "honey pot" for the compiler: we present two overloaded candidate functions
** with a different return type; by investigating the resulting return type we're able to figure
** out the overload actually picked by the compiler.
**
** This header provides some pre-configured tests, available as macros. Each of them contains
** a template based on the described setup, containing a \em probe type expression at some point.
** The key is to build this probe expression in a way that it's valid only if the type in question
** has a specific property
** The key is to build this probe expression in a way that it is valid if and only if the
** type in question exhibits a specific property.
**
** - if the type should contain a nested type of typedef with a specific name, we simply use
** - if the type should contain a nested type or typedef with a specific name, we simply use
** this nested type in the signature of the overloaded function
** - if the type should contain a \em member with a specific name, we initialise a member pointer
** within a probe template with this member (if there isn't such a member, the probe template
@ -75,8 +75,8 @@
** - function signatures need to match precisely, including const modifiers
** - the generated metafunction (template) uses a type parameter 'TY', which could
** shadow or conflict with an type parameter in the enclosing scope
** - the member and function checks rely on member pointers, which generally rely on
** the explicit static type. These checks don't see any inherited members / functions.
** - the member and function checks rely on member pointers, which generally refer to
** the explicit static type. These checks won't see any inherited members / functions.
** - obviously, all those checks are never able to detect anything depending on runtime
** types or RTTI
**

14
wiki/renderengine.html
View file

@ -2403,11 +2403,11 @@ Thus, the Proc-Layer exposes (one or several) facade interfaces for the GUI to u
Probably the most important aspect regarding the GUI integration is how to get [[access to and operate on the Session|SessionInterface]]. More specifically, this includes [[referring to individual objects|MObjectRef]]. On top of these generic access mechanisms, we create a [[proxy GUI model|GuiModel]] for binding. The interface of this GUI model is tailored for display and translation into UI entities.</pre>
</div>
<div title="GuiModel" creator="Ichthyostega" modifier="Ichthyostega" created="201410170142" modified="201501061108" tags="GuiIntegration design draft" changecount="9">
<div title="GuiModel" creator="Ichthyostega" modifier="Ichthyostega" created="201410170142" modified="201511202206" tags="GuiIntegration design draft" changecount="11">
<pre>Building a layered architecture is a challenge, since the lower layer //really// needs to be self-contained, while prepared for usage by the higher layer.
A major fraction of all desktop applications is written in a way where operational logic is built around the invocation from UI events -- what should be a shell turns into a backbone. One possible way to escape from this common anti pattern is to introduce a mediating entity, to translate between two partially incompatible demands and concerns: Sure, the &quot;tangible stuff&quot; is what matters, but you can not build any significant piece of technology if all you want is to &quot;serve&quot; the user.
Within the Lumiera GTK GUI, we use a proxying model as a mediating entity. It is based upon the ''generic aspect'' of the SessionInterface, but packaged and conditioned in a way to allow a direct mapping of GUI entities on top. The widgets in the GUI can be conceived as decorating this model. Callbacks can be wired back, allowing to transform UI events into a stream of commands for the Proc-Layer sitting below.
Within the Lumiera GTK UI, we use a proxying model as a mediating entity. It is based upon the ''generic aspect'' of the SessionInterface, but packaged and conditioned in a way to allow a direct mapping of GUI entities on top. The widgets in the UI can be conceived as decorating this model. Callbacks can be wired back, so to transform user interface events into a stream of commands for the Proc-Layer sitting below.
The GUI model is largely comprised of immutable ID elements, which can be treated as values. A mutated model configuration in Proc-Layer is pushed upwards as a new structure and translated into a ''diff'' against the previous structure -- ready to be consumed by the GUI widgets; this diff can be broken down into parts and consumed recursively -- leaving it to the leaf widgets to adapt themselves to reflect the new situation.
&amp;rarr; [[Building blocks of the GUI model|GuiModelElements]]
@ -2419,7 +2419,7 @@ We acknowledge that the gui model is typically used from within the GUI event di
The forwarding of model changes to the GUI widgets is another concern, since notifications from session mutations arrive asynchronous after each [[Builder]] run. In this case, we send a notification to the widgets registered as listeners, but wait for //them// to call back and fetch the [[diffed state|TreeDiffModel]]. This callback will be scheduled by the widgets to perform in the GUI event thread.
</pre>
</div>
<div title="GuiModelElements" creator="Ichthyostega" modifier="Ichthyostega" created="201501061138" modified="201505081459" tags="GuiIntegration design draft img" changecount="40">
<div title="GuiModelElements" creator="Ichthyostega" modifier="Ichthyostega" created="201501061138" modified="201511202314" tags="GuiIntegration design draft img" changecount="44">
<pre>''Building Blocks for the User Interface Model and Control structure''
The fundamental pattern for building graphical user interfaces is to segregate into the roles of __M__odel, __V__iew and __C__controler ([[MVC|http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]]). This approach is so succesful, that it turned into a de-facto standard in commen UI toolkit sets. But larger, more elaborate and specialised applications introduce several cross cutting concerns, which create a tension within this MVC solution pattern.
[&lt;img[UI-Bus and GUI model elements|uml/fig158213.png]]
@ -2438,7 +2438,7 @@ While GTK -- especially in the object oriented incantation given by Gtkmm -- hoo
;local state
:recommendation is to have widget local state represented //within the UI toolkit (GTK).// On loosing bus connection, any element should disable itself or maybe even shut down.
;updates
:tangible UI elements are //passive.// Any update and mutation, on notification from the bus, is [[pulled from the model|GuiModelUpdate]]. The individual element is thus required to update itself (and its children recursively) into compliance with the provided state.
:tangible UI elements are //passive.// User interaction just results in messages sent to the bus. Any update and mutation, on notification from the bus, is [[pulled from the model|GuiModelUpdate]]. The individual element is thus required to update itself (and its children recursively) into compliance with the provided state.
@ -2448,7 +2448,7 @@ The workspace starts out with a single element, corresponding to the »model roo
Speaking of implementation, this state and update mechanics relies on two crucial provisions: Lumiera's framework for [[tree diff representation|TreeDiffModel]] and the ExternalTreeDescription, which is an abstracted, ~DOM-like rendering of the relevant parts of the session; this model tree is comprised of [[generic node elements|GenNode]] acting as proxy for [[calls into|SessionInterface]] the [[session model|HighLevelModel]] proper.
</pre>
</div>
<div title="GuiModelUpdate" creator="Ichthyostega" modifier="Ichthyostega" created="201410250121" modified="201506040022" tags="GuiIntegration GuiPattern design decision discuss draft" changecount="31">
<div title="GuiModelUpdate" creator="Ichthyostega" modifier="Ichthyostega" created="201410250121" modified="201511210142" tags="GuiIntegration GuiPattern design decision discuss draft" changecount="38">
<pre>Considerations regarding the [[structure of custom timeline widgets|GuiTimelineWidgetStructure]] highlight again the necessity of a clean separation of concerns and an &quot;open closed design&quot;. For the purpose of updating the timeline(s) to reflect the HighLevelModel in Proc-Layer, several requirements can be identified
* we need incremental updates: we must not start redrawing each and everything on each tiny change
* we need recursive programming, since this is the only sane way to deal with tree like nested structures.
@ -2484,7 +2484,7 @@ A relevant question to be settled is as to where the core of each change is cons
* alternatively, we might incorporate a complete snapshot of all information relevant for the GUI into the GuiModel. Update messages from Proc must be complete and self contained in this case, since our goal is to avoid callbacks. Following this scheme, the first stage of any update would be a push from Proc to the GuiModel, followed by a callback pull from within the individual widgets receiving the notification later. This is the approach we choose for the Lumiera GUI.
!!!information to represent and to derive
The purpose of the GuiModel is to represent an anchor point for the structures //actually relevant for the UI.// To put that into context, the model in the session is not bound to represent matters exactly in the way to be rendered within the GUI. All we can expect is for the //build process// -- upon completion -- to generate a view of the actually altered parts, detailing the information relevant for presentation. Thus we do retain an ExternalTreeDescription of all the information received this way within the GuiModel. Whenever a completed build process sends an updated state, we use the diff framework to determine the actually relevant differences -- both for triggering the corresponding GUI widgets, and for forwarding this focussed diff information to these widgets when they call back from the UI event thread to pull the actual changes.
The purpose of the GuiModel is to represent an anchor point for the structures //actually relevant for the UI.// To put that into context, the model in the session is not bound to represent matters exactly the way they are rendered within the GUI. All we can expect is for the //build process// -- upon completion -- to generate a view of the actually altered parts, detailing the information relevant for presentation. Thus we do retain an ExternalTreeDescription, holding all the information received this way within the GuiModel. Whenever a completed build process sends an updated state, we use the diff framework to determine the actually relevant differences -- both for triggering the corresponding UI widgets, and for forwarding focussed diff information to these widgets when they call back later from the UI event thread to pull actual changes.
!!!switch of typed sub-context
When dealing with structural (tree) diffing, there is a specific twist regarding child nodes of mixed type: In the general case, we can not assume that all children of a given node are of the same kind. The classical example is (X)HTML, where a node has //attributes,// various //nested tags// and //nested text content.// The //generic node// thus must be modelled as having several collections of children -- both ordered and un-ordered collections are possible -- and the content of each such sub-collection is itself polymorphic. This constitutes a challenge for the representation of data within the tree diff format. These difficulties can be overcome as follows
@ -2494,7 +2494,7 @@ When dealing with structural (tree) diffing, there is a specific twist regarding
#we introduce a //bracing construct// into the diff language, to enter a subnode within the diff representation
#the diff is produced and consumed //demand-driven (by pull)//
#whenever a node sees this bracing construct, in invokes the respective child //recursively//
This approach ensures each nested diff is consumed within a properly typed context, without any need of switching types from the outside: the actual consumer of each part of the whole diff description just happens to know the actual meaning of those elements he processes itself, and passes control to others with adequate knowledge for the rest. Changes are broken down and transformed into //atomic changes.// For an internal data exchange, this is sufficient: in the end we're dealing with references to binary data anyway. But when it comes to an external, self-contained representation of diffs, we additionally need a way to attach raw chunks of data corresponding to the description of those atomic changes.
This treatment ensures each nested diff is consumed within a properly typed context, and without any need of switching types from the outside: the actual consumer of each part of the whole diff description just happens to know the actual meaning of those elements he processes itself, and passes control to others with adequate knowledge for the rest. Changes are broken down and transformed into //atomic changes.// For an internal data exchange, this is sufficient: in the end we're dealing with references to binary data anyway. But when it comes to an external, self-contained representation of diffs, we additionally need a way to attach raw chunks of data corresponding to the description of those atomic changes.
&amp;rarr; this is the purpose of the {{{DataCap}}} within our [[generic node element|GenNode]]
</pre>
</div>

72
wiki/thinkPad.ichthyo.mm
View file

@ -4,14 +4,45 @@
<font NAME="SansSerif" SIZE="18"/>
<node CREATED="1434128046296" ID="ID_1900827283" MODIFIED="1434128053553" POSITION="right" TEXT="GUI">
<node CREATED="1434128054470" ID="ID_1166611516" MODIFIED="1434128059666" TEXT="Workflow"/>
<node CREATED="1448070434915" HGAP="64" ID="ID_257833497" MODIFIED="1448070642269" VSHIFT="7">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
innere
</p>
<p>
Struktur
</p>
</body>
</html>
</richcontent>
<arrowlink COLOR="#3a8df0" DESTINATION="ID_1618124128" ENDARROW="Default" ENDINCLINATION="-19;-25;" ID="Arrow_ID_539627804" STARTARROW="Default" STARTINCLINATION="-2;35;"/>
<node CREATED="1448070545132" HGAP="31" ID="ID_1410368513" MODIFIED="1448070598035" TEXT="Element" VSHIFT="-7">
<node CREATED="1448070580927" ID="ID_467382299" MODIFIED="1448070583371" TEXT="Auspr&#xe4;gungen">
<node CREATED="1448070554963" ID="ID_579919554" MODIFIED="1448070559134" TEXT="Widget"/>
<node CREATED="1448070559466" ID="ID_182430638" MODIFIED="1448070560909" TEXT="Controller"/>
</node>
<node CREATED="1448070583679" ID="ID_1248152908" MODIFIED="1448070586147" TEXT="Protokoll"/>
</node>
<node CREATED="1448070547667" ID="ID_669457401" MODIFIED="1448070553662" TEXT="Bus-Terminal">
<node CREATED="1448070601165" ID="ID_1711137699" MODIFIED="1448070603296" TEXT="Methoden"/>
<node CREATED="1448070605948" ID="ID_1779744719" MODIFIED="1448070608272" TEXT="Verhalten"/>
<node CREATED="1448070618434" ID="ID_1925738380" MODIFIED="1448070621878" TEXT="Zuordnung"/>
</node>
</node>
<node CREATED="1434128059966" ID="ID_823283341" MODIFIED="1434128067529" TEXT="Connect">
<node CREATED="1434128071126" ID="ID_1618124128" MODIFIED="1434128074137" TEXT="UI-Bus">
<node CREATED="1434128071126" ID="ID_1618124128" MODIFIED="1448070642269" TEXT="UI-Bus">
<linktarget COLOR="#3a8df0" DESTINATION="ID_1618124128" ENDARROW="Default" ENDINCLINATION="-19;-25;" ID="Arrow_ID_539627804" SOURCE="ID_257833497" STARTARROW="Default" STARTINCLINATION="-2;35;"/>
<node CREATED="1434128297445" ID="ID_1971555917" MODIFIED="1434128300889" TEXT="Nachrichtenformat"/>
<node CREATED="1434128301525" ID="ID_187622243" MODIFIED="1434128303993" TEXT="Parallelit&#xe4;t"/>
<node CREATED="1434128332277" ID="ID_33025591" MODIFIED="1434128337777" TEXT="Deregistrierung"/>
<node CREATED="1434128310005" ID="ID_644247390" MODIFIED="1434128318561" TEXT="Knoten-ID"/>
</node>
<node CREATED="1434128074725" ID="ID_933994138" MODIFIED="1443741968332" TEXT="Diff-System">
<node CREATED="1448063874479" ID="ID_739054690" MODIFIED="1448063878154" TEXT="UI-Modell"/>
<node CREATED="1434128074725" FOLDED="true" ID="ID_933994138" MODIFIED="1448063763273" TEXT="Diff-System">
<icon BUILTIN="pencil"/>
<node CREATED="1434128278990" ID="ID_106354755" MODIFIED="1434128283641" TEXT="Diff-Darstellung"/>
<node CREATED="1434128267381" ID="ID_823706141" MODIFIED="1434128551925" TEXT="List-diff">
@ -2140,6 +2171,13 @@
</node>
</node>
</node>
<node CREATED="1448063880238" ID="ID_159570161" MODIFIED="1448063892056" TEXT="Zyklus">
<node CREATED="1448063893293" ID="ID_1135705575" MODIFIED="1448063895640" TEXT="initial"/>
<node CREATED="1448063896300" ID="ID_1403759288" MODIFIED="1448063901895" TEXT="Zuordnung"/>
<node CREATED="1448063902387" ID="ID_1822852634" MODIFIED="1448063907367" TEXT="Aktion"/>
<node CREATED="1448063908243" ID="ID_474614648" MODIFIED="1448063912622" TEXT="Update"/>
<node CREATED="1448063913618" ID="ID_1967302094" MODIFIED="1448063944777" TEXT="Ende"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#c9d1da" COLOR="#2d2198" CREATED="1439664045448" HGAP="240" ID="ID_21531707" MODIFIED="1439664212589" POSITION="left" TEXT="Info" VSHIFT="-500">
@ -2718,8 +2756,7 @@
Tests mit TypeIDs <font color="#ed0b08">scheitern</font>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="clanbomber"/>
</node>
<node CREATED="1447983008594" ID="ID_8361302" MODIFIED="1447990965857" TEXT="L&#xf6;sung f&#xfc;r std::hash finden">
@ -2742,8 +2779,7 @@
Doku durchk&#228;mmen nach M&#252;ll
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<font NAME="SansSerif" SIZE="12"/>
<icon BUILTIN="full-1"/>
<icon BUILTIN="button_ok"/>
@ -2799,8 +2835,7 @@
knappe Kennzeichnung des Releases in den Kommentar
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="full-2"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1446480787391" ID="ID_1824008353" MODIFIED="1446480798862" TEXT="admin/scons/Setup.py"/>
@ -2827,8 +2862,7 @@
denn wir wollen keine DEB-Info im Master haben!
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="full-3"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1446481302159" ID="ID_1330024662" MODIFIED="1447567060657" TEXT="Release-Zweig">
@ -2854,8 +2888,7 @@
die unmittelbaren Release-Dokumente durchgehen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="full-4"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1446481123991" ID="ID_1319204482" MODIFIED="1446481126435" TEXT="README"/>
@ -2882,8 +2915,7 @@
Sollte konfliktfrei sein
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="full-5"/>
<icon BUILTIN="button_ok"/>
</node>
@ -2916,8 +2948,7 @@
...das hei&#223;t bauen und hochladen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="full-7"/>
<node CREATED="1447566826434" HGAP="0" ID="ID_808634666" MODIFIED="1447990847522" TEXT="Bugfix-Release 0.pre.03-2" VSHIFT="-1">
<icon BUILTIN="idea"/>
@ -3060,8 +3091,7 @@
mit gcc-5 gebaute Tests <b><font color="#d40262">scheitern</font></b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1447990760017" ID="ID_413820913" MODIFIED="1447990801156">
@ -3074,8 +3104,7 @@
bauen mit gcc-4.9 <i>nicht m&#246;glich</i>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
@ -3085,8 +3114,7 @@
es gibt Probleme beim Linken mit den Boost-Libraries, die auf Ubuntu/wily mit gcc-5 gebaut sind.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="smily_bad"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#990000" CREATED="1447990802803" ID="ID_1667893677" MODIFIED="1447990809916" TEXT="ABBRUCH"/>