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).
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!
...but the whole design looks still overengineered. See #388
- should get rid of the explicit specialisation
- always use a function signature and thus have arguments?
- why inheriting from the wrapper?
still puzzled why this instantiation of MultiFact fails to compile with GCC 4.8
so I'm bound to understand why the types involved
need indeed to be are structured the way they are right now.
previous versions used to resolve this ambiguity in favour of a ctor call,
but now the compiler treats such constructs as function definition;
this is reasonable, since C++11 introduced the notion of a "generalised
initialisation", which is always written as a (possibly empty) list
in braces.
In these specific cases here, we just omit the empty parens
Since we have now a generic bridge to supply std::hash functions based on
an exisiting boost::hash function, we removed the explicit std::hash
specialisation for "Placement-ID".
This caused the PlacementIndex implementation to fail at compilation
with a quite obscure error, which in fact seems to be caused by the
absence of any specific specialisation. The symptom is that a iterator
range could not be assigned to the predefined iterator type of
std::unordered_multimap, due to a mismatch in the embedded traits type
__umap_traits<__cache_default<_Key, _Hash>::value>>
While I didn't track down that problem entirely, to verify my hypothesis,
the problem can be avoided by using the default -- which is now to
pick up an existing boost::hash function for this type and use this
to generate the std::hash function.
right now we have to defeat an unfortunate static assertion in
the standard library, which is expected to go away in the future.
We use a hack to hijack the problematic definition with the preprocessor,
which requires our header to be first.
NOTE: this header contains a potentially dangerous, temporary workaround
to defeat the static assertion in the default implementation of std::hash,
as shipped with GCC 4.7.x
This assertion turns out to be detrimental all kinds of metaprogramming
based solutions, since it defeats SFINAE. It is expected to be removed
in GCC 4.8
the rules are:
- our own headers go before any library headers
- all headers need to be spelled relative to include root
- ensure that gtk is always included via gui/gtk-base.hpp
c++11 uses another hashtable implementation.
This uncovered some poorly written tests, which relied on
objects being returned in a specific order. As far as poissible,
we're using generic query functions now to get our test objects.
But these tests still rely on a specifically crafted test index content,
which as such is acceptable IMHO. The only remaining problem is
that we check the order of generated output in some tests, and this
order is still implementation dependent.
a real fix would be to rewrite the test to collect the retrieved
values and do a structural verification of the results. This
would mean to write a lot of code for such a marginal topic,
which was implemented just for sake of completenes anyway.
Hopefully my lack of "motivation" doesn't backfire eventually ;-)
Conversion means automatic conversion. In our case,
what we need ist the ability to *construct* a bool from
our (function) object -- while functors aren't automatically
convertible to bool. Thus we use one of the new predicates
from <type_traits>
...uncovered by switching to c++11
When invoking an individual test, we used to erase
the 0-th cmdline argument, which happens to be allways
the name of the test being invoked. Yet none of our
tests actually complied to that contract. Rather,
all tests taking arguments access them by 1-based
argument index. Previously, the argument values just
happened to be still in memory at the original location
after erasing the 0st element.
"Fixed" that by changing the contract. Now, the 0th argument
remains in place, but when there are no additional arguments,
the whole cmdline is cleared.
This is messy, but the test runer needs to be rewritten
entirely, the whole API is clumsy and dangerous. Ticket #289
* use a development snapshot of lib SigC including the recent C++11 adaptations
* never include whole namespaces. Here we got a clash between std::bind and sigc::bind
* use lambdas
* to make the binding code more readable
* to take the nested invocations apart, which resolves the return type ambiguity
In the November developer meeting, Christian and I agreed that
it's best to remove that offending LUID specifications altogether.
Those embedded LUIDs where one of the issues blocking the transition to C++11
This is a partial and preliminary fix; we had an occasional
numeric overflow on 32bit platforms in some tests.
The complete fix will be to introduce a typedef and then
rework the relevant APIs (which are preliminary anyway,
thus no urge right now)
our front-end for boost::format, the class lib::_Fmt
was lacking an reliable specialisation for long and ulong.
This is due to the notorious problem of these types being
of platform dependant size. As a fix, we're speclialising
explicitly for int16_t, int32_t and int64_t and avoid the
common names 'short', 'int' and 'long' alltogether.
And especially for non-64bit-platform (NONPORTABLE)
we add an explicit specialisation for long
The recommendation is to use the link flag --no-undefined
and to fed *all* dependencies to the respective link step.
This changeset enables this strict linking of dependencies.
It turned out that our dependencies were already sane
(with the sole exception of a direct dependency to X-Lib
in the XV viewer widget)
- upgrade the configuration to a current version
- provide a frontpage with cross-links to other documentation
- define a set of modules; relevant classes and files can be
added to these, to create a exploration path for new readers
- fix a lot of errors in documentation comments
- use a custom configuration for the documentation pages
- tweak the navigation, the sections and further arrangements
to make them stand out more prominently, some entity comments
where started with a line of starts. Unfortunately, doxygen
(and javadoc) only recogise comments which are started exactly
with /**
This caused quite some comments to be ignored by doxygen.
Credits to Hendrik Boom for spotting this problem!
A workaround is to end the line of stars with *//**
When a ctor throws, the dtors of sub-objects have already been
invoked. The object itself never existed, strictly speaking,
and thus the dtor must not be invoked. Usually the runtime system
handles matters automatically this way, but since we're doing
here placement new into an array, we're responsible ourselves
This error was uncovered by compiling with Clang.
GCC automatically neutralised this erroneous dtor invocation.
This removes the central clean-up registry;
Instead, now the InstanceHolder manages the lifecycle of
the service instances placed into static memory; the net effect
is that DependencyFactory and instances are created and destroyed
together, locally for each usage scope
We don't need this ability and it pushes us into using a
central registry. This solution turned out to be problematic
when loading dynamic libraries (plug-ins).
this check may look weird, but in fact a similar check in the
old version of the singleton factory helped us spot a problem
with Clang, most likely but of the compiler or runtime system
Clang doesn't allow to declare a private nested class as friend.
This is unfortunate, but likely correct to the letter of the standard.
As a workaround, now we're creating the instances within a static
function of DependencyFactory -- in the end this improves readability
A second issue fixed with this changeset is the scope of the
marker function. Clang is right, this isn't ADL, thus an inline
friend definition is simply not visible outside the class.
lib::Depend<TY> works as drop-in replacement for lib::Singleton<TY>
This changeset removes the convoluted special cases like
SingletonSub and MockInjector.
explanation: we use pthread_once to define a mutex type descriptor,
used to define some of our mutexes as recursive mutexes. Now,
pthread_once relies on a counter stored in a given location;
we used a non-exported global var for this counter.
Unfortunately this ties the mutex initialisation to the static
initialisation of the compilation unit holding this counter variable.
Theoretically it would be possible (we never observed such an incident)
that, during static initialisation, a singleton was brought up,
which requires a class-scoped lock, implemented as recursive mutex.
And it would be possible for this singleton locking to happen prior
to initialisation of the mentioned counter variable.
As a fix, I've moved the counter varialbe into a function scoped
static variable, since that is guaranteed by the C++ runtime system
to be initialised at first usage of the function, irrespective of the
initialisation order of the enclosing compilation units
