planning: next steps towards command invocation (#1070)
This commit is contained in:
parent
41ea59176c
commit
40eba94917
2 changed files with 36 additions and 14 deletions
|
|
@ -1539,9 +1539,9 @@ To support this handling scheme, some infrastructure is in place:
|
|||
* performing the actual execution is delegated to a handling pattern object, accessed by name.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="CommandInvocationAnalysis" creator="Ichthyostega" modifier="Ichthyostega" created="201702142329" modified="201702160147" tags="draft impl GuiPattern example discuss" changecount="12">
|
||||
<div title="CommandInvocationAnalysis" creator="Ichthyostega" modifier="Ichthyostega" created="201702142329" modified="201703031814" tags="draft impl GuiPattern example discuss" changecount="13">
|
||||
<pre>//This page is a scrapbook to collect observations about command invocation in the UI//
|
||||
{{red{2/2017}}} the goal is to shape some generic patterns of InteractionControl (&rarr; GuiCommandBinding)
|
||||
{{red{2/2017}}} the goal is to shape some generic patterns of InteractionControl (&rarr; GuiCommandBinding, &rarr; GuiCommandCycle)
|
||||
|
||||
!Add Sequence
|
||||
The intention is to add a new sequence //to the current session.//
|
||||
|
|
@ -2542,8 +2542,10 @@ In a typical editing application, the user can expect to get some visual clue re
|
|||
To start with, mostly this means to avoid a naive approach, like having code in the UI to pull in some graphics from media files. We certainly won't just render every media channel blindly. Rather, we acknowledge that we'll have a //strategy,// depending on the media content and some further parameters of the clip. This might well just be a single ''pivot image'' chosen explicitly by the editor to represent a given take. And the actual implementation of content preview rendering will largely be postponed until we get our rendering engine into a roughly working state.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="GuiCommandBinding" creator="Ichthyostega" modifier="Ichthyostega" created="201511272246" modified="201609091641" tags="design decision operational GuiPattern GuiIntegration draft discuss" changecount="26">
|
||||
<div title="GuiCommandBinding" creator="Ichthyostega" modifier="Ichthyostega" created="201511272246" modified="201703031818" tags="design decision GuiPattern GuiIntegration discuss" changecount="30">
|
||||
<pre>The question //how to connect the notion of an ''interface action'' to the notion of a ''command'' issued towards the [[session model|HighLevelModel]].//
|
||||
* actual design of command invocation in the UI &rarr; GuiCommandCycle
|
||||
* study of pivotal action invocation situations &rarr; CommandInvocationAnalysis
|
||||
|
||||
!prerequisites for issuing a command
|
||||
Within the Lumiera architecture, with the very distinct separation between [[Session]] and interface view, several steps have to be met before we're able to operate on the model.
|
||||
|
|
@ -2577,9 +2579,18 @@ This contrastive approach attempts to keep knowledge and definition clustered in
|
|||
* if finally some button is hit, the local event binding can issue the command right away, as preconfigured in this //enablement binding,// by accessing just any UI-Bus terminal at reach within that context
|
||||
|
||||
''Lumera decides to take the latter apptoch'' -- resulting in a separation between immediate low-level UI element reactions, and anything of relevance for the behaviour of the UI. The widget code embodies the low-level UI element reactions and as such becomes more or less meaningless beyond local concerns of layout and presentation. If you want to find out about the behaviour of the UI, you need to know where to look, and you need to know how to read and understand those enablement rules. Another consequence is the build-up of dedicated yet rather abstract state tracking facilities, hooking like an octopus into various widgets and controllers, which might work counter to the intentions behind the design of common UI toolkit sets.
|
||||
&rarr; GuiCommandCycle
|
||||
</pre>
|
||||
</div>
|
||||
<div title="GuiConnection" modifier="Ichthyostega" created="200812050543" modified="201701140732" tags="GuiIntegration overview" changecount="8">
|
||||
<div title="GuiCommandCycle" creator="Ichthyostega" modifier="Ichthyostega" created="201703031817" modified="201703031837" tags="design operational GuiPattern GuiIntegration draft discuss" changecount="3">
|
||||
<pre>//the process of issuing a session command from the UI//
|
||||
Within the Lumiera UI, we distinguish between core concerns and the //local mechanics of the UI.// The latter is addressed in the usual way, based on a variation of the [[MVC-Pattern|http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]]. The UI toolkit set, here the GTK, affords ample ways to express actions and reactions within this framework, where widgets in the presentation view are wired with the corresponding controllers vice versa (GTK terms these connections as //"signals"//, we rely on {{{libSigC++}}} for implementation).
|
||||
A naive approach would extend these mature mechanisms to also cover the actual functionality of the application. This compelling solution allows quickly to get "something tangible" up and running, yet -- on the long run -- inevitably leads to core concerns being tangled into the presentation layer, which in turn becomes hard to maintain and loaded with "code behind". Since we are here "for the long run", we immediately draw the distinction between UI mechanics and core concerns. The latter are, by decree and axiom, required to perform without even an UI layer running. This decision gives rise to the challenge how to form and integrate the invocation of ''core commands'' into the presentation layer.
|
||||
|
||||
In a nutshell, we understand each such core command as a ''sentence'', with a //subject//, a //predication//, which is the command script in ~Proc-Layer and can be represented by an ID, and possibly additional arguments. And the key point to note is: //such an action sentence need to be formed, before it can be issued.//
|
||||
</pre>
|
||||
</div>
|
||||
<div title="GuiConnection" modifier="Ichthyostega" created="200812050543" modified="201703031816" tags="GuiIntegration overview" changecount="9">
|
||||
<pre>All communication between Proc-Layer and GUI has to be routed through the respective LayerSeparationInterfaces. Following a fundamental design decision within Lumiera, these interface are //intended to be language agnostic// &mdash; forcing them to stick to the least common denominator. Which creates the additional problem of how to create a smooth integration without forcing the architecture into functional decomposition style. To solve this problem, we rely on ''messaging'' rather than on a //business facade// -- our facade interfaces are rather narrow and limited to lifecycle management. In addition, the UI exposes a [[notification facade|GuiNotificationFacade]] for pushing back status information created as result of the edit operations, the build process and the render tasks.
|
||||
|
||||
!anatomy of the Proc/GUI interface
|
||||
|
|
@ -2592,7 +2603,7 @@ By all means, we want to avoid a common shared data structure as foundation for
|
|||
|
||||
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. The collaboration between both sides is based on a ''common structural understanding'', which is never fully, totally formed 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,// 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.
|
||||
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. (&rarr; GuiCommandCycle)
|
||||
</pre>
|
||||
</div>
|
||||
<div title="GuiCustomWidget" creator="Ichthyostega" modifier="Ichthyostega" created="201410250002" modified="201611182349" tags="GuiPattern discuss decision draft" changecount="64">
|
||||
|
|
@ -3252,7 +3263,7 @@ The InstanceHandle is created by the service implementation and will automatical
|
|||
&rarr; see [[detailed description here|LayerSeparationInterfaces]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="InteractionControl" creator="Ichthyostega" modifier="Ichthyostega" created="201511272315" modified="201702162049" tags="design decision Concepts GuiPattern draft discuss" changecount="14">
|
||||
<div title="InteractionControl" creator="Ichthyostega" modifier="Ichthyostega" created="201511272315" modified="201703031747" tags="design decision Concepts GuiPattern draft discuss" changecount="15">
|
||||
<pre>This overarching topic is where the arrangement of our interface components meets considerations about interaction design.
|
||||
The interface programming allows us to react on events and trigger behaviour, and it allows us to arrange building blocks within a layout framework. Beyond that, there needs to be some kind of coherency in the way matters are arranged -- this is the realm of conventions and guidelines. Yet in any more than trivial UI application, there is an intermediate and implicit level of understanding, where things just happen, which can not fully be derived from first principles. It is fine to have a convention to put the "OK" button right -- but how to we get at trimming a clip? How do we how we are to get at trimming a clip? if we work with the mouse? or the keyboard? or with a pen? or with a hardware controller we don't even know yet? We could deal with such on a case-by-case base (as the so called reasonable people do) or we could aim at an abstract intermediary space, with the ability to assimilate the practical situation yet to come.
|
||||
|
||||
|
|
@ -3270,13 +3281,13 @@ The interface programming allows us to react on events and trigger behaviour, an
|
|||
&rarr; detailed [[analysis how commands are to be invoked|CommandInvocationAnalysis]]
|
||||
|
||||
!Foundation Concepts
|
||||
The primary insight is, that we build upon a spatial metaphor -- and thus we start out with defining various kinds of //locations.// We express interactions as //happening somewhere...//
|
||||
The primary insight is //that we build upon a spatial metaphor// -- and thus we start out with defining various kinds of //locations.// We express interactions as //happening somewhere...//
|
||||
;work site
|
||||
:a distinct, coherent place where some ongoing work is done
|
||||
:the WorkSite might move along with the work, but we also may leave it temporarily to visit some other work site
|
||||
;the spot
|
||||
:the [[Spot]] is where we currently are -- taken both in the sense of a location and a spotlight
|
||||
:thus a spot is always at some work site, but it can be navigated to another one
|
||||
:thus a spot is potentially at some work site, but it can be navigated to another one
|
||||
;focus
|
||||
:the concrete realisation of the spot within a given control system
|
||||
;control system
|
||||
|
|
|
|||
|
|
@ -2011,6 +2011,9 @@
|
|||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1488494870418" ID="ID_1929432332" MODIFIED="1488494879041" TEXT="TODO: InvocationTrail">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1488566247742" ID="ID_254774965" MODIFIED="1488566261845" TEXT="muß doch die Architktur klären">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1488423763585" ID="ID_968726788" MODIFIED="1488423768988" TEXT="Schließen"/>
|
||||
<node CREATED="1488494907118" ID="ID_1932633471" MODIFIED="1488494915320" TEXT="Speichern-Als">
|
||||
|
|
@ -2174,15 +2177,23 @@
|
|||
<node CREATED="1486763350764" ID="ID_1309124609" MODIFIED="1488420106546" TEXT="Aufgaben">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1486763355739" ID="ID_745725927" MODIFIED="1486763370261" TEXT="Bindung für Aktionen bereitstellen"/>
|
||||
<node CREATED="1488566356774" ID="ID_969011841" MODIFIED="1488566387030" TEXT="Ankerpunkt zum Bilden der Commands">
|
||||
<node CREATED="1488566405248" ID="ID_355508260" MODIFIED="1488566425745" TEXT="auffinden der Command-IDs"/>
|
||||
<node CREATED="1488566427445" ID="ID_567418101" MODIFIED="1488566441831" TEXT="InteractionStateManager">
|
||||
<node CREATED="1488566447466" ID="ID_1978593319" MODIFIED="1488566452134" TEXT="hängen darunter"/>
|
||||
<node CREATED="1488566452538" ID="ID_1569803797" MODIFIED="1488566471539" TEXT="werden transient gebilet"/>
|
||||
</node>
|
||||
<node CREATED="1488566472583" ID="ID_1307397775" MODIFIED="1488566481305" TEXT="InvocationTrail beziehen"/>
|
||||
</node>
|
||||
<node CREATED="1486763376960" ID="ID_1618020758" MODIFIED="1486763385091" TEXT="Zugang zu den Timelines"/>
|
||||
<node CREATED="1486763385591" ID="ID_6651258" MODIFIED="1486763391202" TEXT="Zugang zum Asset-Management"/>
|
||||
<node CREATED="1486763391862" ID="ID_1568245541" MODIFIED="1486763397977" TEXT="Zugang zur Konfiguration"/>
|
||||
<node CREATED="1486763408780" ID="ID_520762274" MODIFIED="1486763417950" TEXT="Zugang zum persistenten Interface-State"/>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1486768073223" FOLDED="true" HGAP="38" ID="ID_1457876217" MODIFIED="1488423342659" TEXT="konkret" VSHIFT="16">
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1486768073223" HGAP="38" ID="ID_1457876217" MODIFIED="1488566292402" TEXT="konkret" VSHIFT="16">
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
<node CREATED="1486768080502" ID="ID_1759740464" MODIFIED="1487039233982" TEXT="Binde-Kontext für globale Aktionen"/>
|
||||
<node CREATED="1486768086869" FOLDED="true" ID="ID_173538981" MODIFIED="1488423342542" TEXT="Idee/Konzept für kontextabhängige Aktionen">
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1487119208622" FOLDED="true" ID="ID_728171298" MODIFIED="1488423308109" TEXT="Analyse anhand einiger Beispiele">
|
||||
<node CREATED="1486768086869" ID="ID_173538981" MODIFIED="1488566299019" TEXT="Idee/Konzept für kontextabhängige Aktionen">
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1487119208622" FOLDED="true" ID="ID_728171298" MODIFIED="1488566307446" TEXT="Analyse anhand einiger Beispiele">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1488419440935" ID="ID_802346253" MODIFIED="1488419449712" TEXT="add Sequence">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
|
|
@ -2191,7 +2202,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1487119230659" FOLDED="true" ID="ID_651577067" MODIFIED="1488423308109">
|
||||
<node CREATED="1487119230659" ID="ID_651577067" MODIFIED="1488566303378">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
|
|
@ -2355,13 +2366,13 @@
|
|||
<node CREATED="1488492233826" ID="ID_1743746426" MODIFIED="1488492238493" TEXT="Timelines"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1487461436006" FOLDED="true" ID="ID_1721976078" MODIFIED="1488492315161" TEXT="Kooperation">
|
||||
<node CREATED="1487461436006" ID="ID_1721976078" MODIFIED="1488566321429" TEXT="Kooperation">
|
||||
<node CREATED="1487461440509" FOLDED="true" ID="ID_1663368282" MODIFIED="1488423342542" TEXT="CoreService">
|
||||
<node CREATED="1487461456739" ID="ID_1032977850" MODIFIED="1487461471666" TEXT="delegiert UiState">
|
||||
<arrowlink DESTINATION="ID_816848691" ENDARROW="Default" ENDINCLINATION="111;0;" ID="Arrow_ID_792016162" STARTARROW="None" STARTINCLINATION="111;0;"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1487461476736" FOLDED="true" ID="ID_912393863" MODIFIED="1488492313624" TEXT="Actions">
|
||||
<node CREATED="1487461476736" FOLDED="true" ID="ID_912393863" MODIFIED="1488566326476" TEXT="Actions">
|
||||
<node CREATED="1487461484935" ID="ID_951148221" MODIFIED="1487461491098" TEXT="Kontext für globale Aktionen"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue