basically just a function to pick up the container and element type automatically.
The actual implementation is delegated to the exisiting lib::iter_stl::IterSnapshot
Heureka! found out that the C++ standard library exposes a
cross vendor C++ ABI, which amongst others allows to show
object code names and type-IDs in the language-level, human
readable unmangeld form.
Of course, actual application code should not rely on such a
internal representation, yet it is of tremendous help when
writing and debugging unit tests.
Signed-off-by: Ichthyostega <prg@ichthyostega.de>
Actually I arried at the conclusion, that the *receiving* of
a diff representation is actually a typical double-dispatch situation.
This leads to the attempt to come up with a specialised visitor
as standard pattern to handle and apply a diff. Obviously,
we do not want the classical GoF-Visitor, but (yes, we had
that discussion allready) -- well in terms of runtime cost,
we have to deal with at least two indirections anyway;
so now I'm exploring the idea to implement one of these
indirections through a functor object, which at the same time
acts as "Tag" in the diff representation language (instead
of using an enum as tag)
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
The actual problem is not resolved; the pluginloader
should detect the duplicate and not add the handle
to the database initially. Or it should add it
as "duplicate" or "alternate implementation"
Which probably means we need to coder some additional
corner cases. But certainly not now, we have other
more important stuff to do first... we've already
lost the battle against Duke Nukem Forever :-P
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
doh...
this happens when you draft some quite intricate logic and then
get sidelined with other tasks for several years. Mind me, I didn't
even recall that I had treated this whole issue and created
a clean-up thread.
A full fledged implementation would have a real lifecycle and
thus detect the re-entrance; but since none of the components
to be managed by the OutputDirector is even remotely planned
or even coded, the functions were just drafted as stubs.
Which caused us happily to create yet another clean-up thread
whenever the subsystem-runner signalled "please shut down".
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
the problem seems to be the interplay with the installed user
theme; what looks well with one theme is messed up with another
one, quite insidious.
Attempt to settle down on a set of default definitions
for borders and element background colors, which make the
Lumiera Gui "dark" but still respect the user's theme
for geometry and widget style
verified: basically works
todo: better handling of parse errors.
Currently this is treated as an unexpected exception and just
terminates the whole application, without any suitable diagnostics.
This makes working on the stylesheet somewhat brittle. GTK-3 actually
offers a signal to be invoked in case of CSS parsing errors
(see #953)
Comment out the active part of the GdkDisplayer implementation,
but retain the class, to make compilation pass.
With the Switch to GTK-3, only Cairo drawing is supported.
We need a new solution for video display...
Lots off commented out blocks of code
but most issues are related to simple function name changes,
set/get_flags calls, anything that has to do with a Gtk::Style...
Plan of attack from here is to go one-by one of each commented-out or code and update to gtk3 specs.
trying to track down where these messages
GLib-GObject-CRITICAL **: g_object_unref: assertion G_IS_OBJECT (object) failed
are coming from. These appear when iconifying panels.
as always, it turned out that the alledged "compiler bug"
rather was my own sloppyness: I forgot properly to undo a change
I made while fighting with compilation problems: the wrapper in
the factory didn't use std::forward, resulting in a plain flat
slicing copy. This, rightfully, triggered the assertion in the
session query resolver (since a sliced Goal can not be dynamic cast
to a specific Query subclass).
