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.
For the Gnome Docking Library, a recent official version will do.
For the mm-bindings by Fabien Parent we maintain our own debian package
at Lumiera.org/debian (there is no official debian package yet)
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.
This is a somewhat intricate problem. As long as we linked with --no-as-needed,
these problems could not manifest themselves, since all dependencies are spotted
correctly by SCons and thus added as direct children of the executable.
But when we switch to --as-needed linking, the linker will omit some of
the dependencies given from the build system, when the code to be linked
doesn't call directly into these dependencies. But of course dynamic modules
may depend on each other, and indeed, the Lumiera libs do so. Thus
the linker may omit the dependency to liblumierasupport, and just add
a dependency to, say liblumierabackend. But the backend in turn
depends on the support library.
Now the problem is, that when resolving several steps deep into such
a dependency chain, our special relative path resolution scheme fails.
The fix is to give each lumiera module itself another relative path
resolution spec, which overrides at that point the root spec given
for the executable. Thus, we define
- for the executable: "search at $ORIGIN/modules"
- for the modules: "search at $ORIGIN/../modules"
This accounts for the fact, that a module, which is the Origin
for a transitive resolution step, already sits in a subdirectory
below the executable; thus step one level up and devle down into
the hard wired modules directory. Alternatively, we could also
use just "search at $ORIGIN" (i.e. in the same directory).
But assuming that in future we'll roll several core plugins,
which also count as "Lumiera modules", the scheme defined here
is more flexible, since it allows to place those core plugins
into sibling directories.
here we're iterating hash table based collections, consequently
the order of items retrieved *is* implementation dependent and indeed
differs on different platforms and compilers.
In Clang, static object fields are initialised from top to bottom,
but before any other variables in anoymous namespaces. To the contrary,
GCC evaluates *any* initialisation expression in the translation
unit together from top to bottom. Thus, in the clang generated
code, in two cases the static initialisation could use a not yet
constructed local lib::_Fmt formatter object.
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).
the alledged compiler error turned out to be
just plain flat lack of attention on my side.
I forgot to revert an previous experimental change:
The "wrapper" in the factory takes the argument by-value
(I forgot to add he && back in, which I removed while
fighting with other compilation problems)
TODO: the toolfactory needs a redesign anyway,
this was just placeholder code added in a very early
state of the Lumiera project. We have way better memory
managing facilities at hand now
the use of a custom finisihing functor, which is applied
to any generated product. This can be used for registration,
memory management or similar framework aspects
Implement the first simple usage scenario for the
unified MultiFact template, using variadic templates.
NOTE:
- the obvious solution based on std::forward
triggers strange behaviour in GCC-4.7
- the inline lambda in the test case traps the
CLang-3.0 parster with a segfault. Horay!
