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.
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.
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
* 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
- 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 *//**
lib::Depend<TY> works as drop-in replacement for lib::Singleton<TY>
This changeset removes the convoluted special cases like
SingletonSub and MockInjector.
