basically this comes down to provide some convenience fixture
within the test::Nexus, which automatically generates and wires
mock commands.
Not sure if this is even possible to the extent envisioned here
- remove unnecessary includes
- expunge all remaining usages of boost::format
- able to leave out the expliti string(elm) in output
- drop various operator<<, since we're now picking up
custom string conversions automatically
- delete diagnostics headers, which are now largely superfluous
- use newer helper functions occasionally
I didn't blindly change any usage of <iostream> though;
sometimes, just using the output streams right away
seems adequate.
I worked under the erroneous assumption, that Doxygen
will use its internal entity-IDs as the link-IDs when
generating mardown-links. Yes, this seemed logical and
this would be the way I'd implement it....
But seemingly, Doxygen is not so consistent when it
comes to questions of syntax. The same holds true for
markdown, which lacking a coherent definition anyway.
Another problem is that Doxygen's auto-link generation
frequently fails, for reasons not yet clear to me.
Sometimes it seems to be necessary to give it a nudge
by including the \ref command. While I'm not willing
to go into focussed invstigation of Doxygen syntax
right now, at least I've done a search-and-replace
to remove the malformed links I've written the
last days
the initial draft of this concept is in place now, and
the first round of unit tests pass. I've got some understanding
of the purpose of the interactions and involved elements
and I'm confident this design is evolving in a sane way.
Note: extensive documentation is in the TiddlyWiki,
here I've just pasted and reworded some paragraphs from there
and integrated them into the Doxygen docs
Explanation: sigC++ was already linked as transitive dependency
from gtkmm, since it is used for the "signal-slot" system wihin GTK.
But now we want to use sigC++ itself from our generic UI-Backbone,
so we need to pick up the additional compiler and linker flags
and use them when building the relevant parts of both the application
and the test suite
at the point when we're connecting a new node to the UI-Bus,
the new node's BusTerm is not yet initialised, since we need
the uplink connection we're about to create for setting up
this BusTerm.
Consequently, the new nodes's ID is not yet initialised,
so we need to pass this endpoint-ID explicitly to the
registration function.
since, by definition, the Nexus is "the" up-link,
all we need is clever overriding of the relevant
handling functions, so the nexus will care for the routing,
while the CoreService cares for command and presentation
state handling
next step will be to rig the mock element and set up
and cover the basic / generic element behaviour
This changeset
- adapts the (planned) unit test to the semantic of
the EventLog, which is now fully implemented
- adjusts the function names on the public Tangible interface,
to be better in line with the naming convention of the
corrsponding operations on the UI-Bus:
* "mark" operations are towards the UI element
* "note" messages are from the UI element towards some
state manager, which can be reached via the bus
...providing the standard implementation of UI-Bus connectivity.
It seems reasonable to place all of the UI-Bus implementation into
a single translation unit
what you see here now is just the tip of the icebearg...
If we follow this route, the Lumiera UI will become way more
elaborate and responsive than average desktop applications
This is a development snaphot pre release of Lumiera.
It features codebase maintenance, upgrade to C++14 and GTK-3
and some work towards a Proc-GUI connection (unfinished)
Update README, AUTHORS, LICENSE and similar release docs.
Note: not fixing all relevant warnings.
Especially, the "-Woverloaded-virtual" of Clang defeats the whole purpose
of generated generic interfaces. For example, our Variant type is instantiated
with a list of types the variant can hold. Through metaprogramming, this
instantiation generates also an embedded Visitor interface, which has
virtual 'handle(TY)' functions for all the types in question
The client now may implement, or even partially implement this Visitor,
to retrieve specific data out of given Variant instance with unknown conent.
To complain that some other virtual overload is now shaddowed is besides the point,
so we might consider to disable this warning altogether
This switches the Lumiera UI from GTK-2 to GTK-3
Unfortunately, this move breaks two crucial features, which have been
disabled for now: the display of video and our custom timeline widget.
Since both of these require some reworking, which in fact has already
started, we prefer to do the library and framework switch right away.
over time, a specific Lumiera code writing style has emerged.
The GUI, as it stood, used somewhat different conventions,
which now have been aligned to the common standard.
Basically we use GNU style, with some adjustments for OO-programming,
we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
it is a widely accepted rule to shape names with the usage site in mind.
Especially this means, that we use the singular form for all kinds
of collections and assortments.
Thus, the namespace should be called "widget" not "widgets",
because at usage site this becomes gui::widget::TimelineWidget
Likewise for "dialogs" and "pannels"
previously this operation was named 'attach', which an be confused
with attching an object to this location. Indeed, the session interface
even offers such an attach function. By renaming the focus moving
operation into QueryFocus::shift(Scope), this ambiguity is resolved
This is the first step towards a generic backbone to connect
any GUI elements to the session within Proc-Layer.
It is based on a spefic understanding of Model-View-Controller,
which turns the Model-Controller interactions into messages.
initial considerations; there is a concurrency problem, since
all of session handling within Proc is deliberately not threadsafe.
Thus the decision is to make this the gui::model::SessionFacade's responsibility
Mark parts of the timeline state handling which will certainly
not be retained: any part where the GUI widgets "hold" some kind
of model. GUI widgets shall be *mapped upon* a model representation
and *wired* with callbacks.
Especially I am suspicious when GUI presentation code "reaches into"
any kind of model data structure to find out something. It should
be the other way round (dont call us, we call you)
actually we should make our timeline a real custom widget,
and do it according to the letter. I.e. really implement
all those callbacks which are recommended, but no other
callbacks.
This has the additional benefit of being able to retrieve
the drawing style in the official way, and define our own
CSS classes, which can be styled by the user in a systematic way.
This is not really a solution, but kind of narrowes down the problem.
Our GUI uses an obsolete C-ish approach at releasing resources at
several points. This is probably a left-over from earlier days.
Especially since we started out with libGDL without C++ wrappers.
And at that time, we didn't use smart-pointers, as we should do,
but we tried to do things manually, which is an approach which never
works in an event driven and condition based environment. Goto fail.
Here I just commented out the manual clean-up code from several dtors.
The real solution would be not to allocate these resources through
the raw C calls at first place, but rather use the mm-wrappers
and leave it to them to unwind at the right moment.
TODO:
- scan the GUI code for *every* instance where we still muck around with gobjects
and either replace that by a mm-wrapper, or wrap it in a smart handle.
- make sure that *all* dtors are either empty, or really airtight and EX_FREE
Our GUI shutdown logic looks rather confused. Why the hell do
some widgets "unregister" themselves in a dtor. This should never
be necessary. Maybe it's a leftover from C-style programming
and obsolete now, after the switch to GDLmm
