The build should not add deprecated/ into the default INCLUDE paths, so
that deprecated headers are clearly separated; this will make it easier
to get rid of them when we branch out for 2.0.
Instead of showing the full timestamp for debugging messages that happen
within a second, showing the delta from the previous full timestamp can
be more useful when debugging; this allows immediately seeing the time
difference, instead of doing the math in our heads.
The example code that is meant to be XIncluded into the API reference
should not be part of the interactive test suite: it's code that it is
meant to be used as a reference implementation - whereas the interactive
test suite should be allowed to be lean and test behaviour even in nasty
ways. In short: the test suite should not be the place where we show off
idiomatic code for educational purposes.
The introspection scanner has become slightly more annoying, in the hope
that people start fixing their annotations. As it turns out, it was the
right move.
It's possible to run Clutter with the 'null' input backend, which means
that clutter_device_manager_get_default() may return NULL. In the future
we may add a default dummy device manager, but right now it's safer to
just add a simple NULL check in the places where we ask for the device
manager.
It is sometimes useful to be able to have better control on when a
repaint function is called. Currently, all repaint functions are called
prior to the stages update phase of the frame processing.
We can introduce flags to represent the point in the frame update
process in which we wish Clutter called the repaint function.
As a bonus, we can also add a flag that causes adding a repaint function
to spin the master clock.
GLib has a "diagnostic mode" switch that can be checked to enable debug
messages on deprecated properties and signals, as these are purely
run-time constructs, and as such cannot be caught by compiler warnings.
The diagnostic mode is toggled by a simple environment variable, and
can be used to ease porting of application code.
We can use something similar to mark deprecated virtual functions and
other run-time constructs; to avoid collisions, we should use our own
environment variable, CLUTTER_ENABLE_DIAGNOSTIC.
There was an #ifdef'd section of code for profiling that was using the
wrong variable name so it would not build.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Since we have a _clutter_debug_message() function compiled in
unconditionally we have no further need for the equivalent conditional
version defined in clutter-profile.[ch]: we can simply do the work in
one function.
We still ship clutter_get_show_fps() and clutter_get_debug_enabled() as
public entry points. Yet another case of missing API review prior to the
1.0 release, so really the bucket stops around my desk.
Let's deprecate these two useless functions, and reduce the API
footprint of Clutter.
This function should have never been made public in the first place; its
output depends on a configuration option of Clutter, and it's basically
useful only for internal debugging.
Make it consistent across the various build options (with or without
profiling enabled), and add a timestamp using the monotonic clock to
every debug message.
Setting the default frame rate does not do anything even remotely
useful, unless synchronization to the vertical refresh rate is also
disabled - which can only be done through environment variable or
through configuration file. Having a programmatic way to change the
default frame rate is, thus, completely pointless.
Changing the default frame rate through environment variable and
configuration file is still allowed.
Instead of defining new symbols for the windowing systems enabled at
configure time, we can reuse the same symbols for both the compile time
and run time checks, e.g.:
#ifdef CLUTTER_WINDOWING_X11
if (clutter_check_windowing_backend (CLUTTER_WINDOWING_X11))
/* use the clutter_x11_* API */
else
#endif
#ifdef CLUTTER_WINDOWING_WIN32
if (clutter_check_windowing_backend (CLUTTER_WINDOWING_WIN32))
/* use the clutter_win32_* API */
#endif
This scheme allows us to ensure that the input system namespace is free
for us to use and select at run time in later versions of Clutter.
Portable code should be allowed to check type backend currently being
used, so that it can use platform-specific API (not just Clutter's).
We don't want to go down the GDK route, with public types for
ClutterBackend and ClutterStageWindow implementations, and use the type
system, e.g.:
#ifdef GDK_WINDOWING_X11
if (GDK_IS_WINDOW_X11 (window))
use_x11_api (window);
else
#endif
#ifdef GDK_WINDOWING_WIN32
if (GDK_IS_WINDOW_WIN32 (window))
use_win32_api (window);
else
#endif
g_critical ("Unsupported backend");
This system would make us expose the backend system, and we want to
still reserve us the option to change the backend system to increase its
granularity — e.g. choosing different input event systems regardless of
the windowing system.
This commit adds a simple function that checks the backend type against
a symbolic constant — the same constant string that can be used to
select the backend at run-time through the CLUTTER_BACKEND environment
variable.
The Clutter backend split is opaque enough that should allow us to just
build all possible backends inside the same shared object, and select
the wanted backend at initialization time.
This requires some work in the build system, as well as the
initialization code, to remove duplicate functions that might cause
conflicts at build and link time. We also need to defer all the checks
of the internal state of the platform-specific API to run-time type
checks.
Since the Windows GUI system is assuming multithreadedness, initializing
locks after entering the GUI portion on Windows is likely to cause
problems[1][2], which results many Clutter programs to crash due to
releasing resources that they did not own.
[1]: Multi-threaded use of GTK+ on Win32 in README.win32 of GTK+
source package
[2]: Explanation of Windows GUI system regarding its multithreadness
assumptions-
http://mail.gnome.org/archives/gtk-list/2011-June/msg00005.html
Or, better, the fact that the behaviour of any Clutter function will be
undefined in case the initialization fails.
The value returned by clutter_init() and friends has to be handled
properly.
The CLUTTER_DEBUG class of debugging flags is meant for debugging notes,
while the CLUTTER_PAINT debugging flags are for changing the output of
the paint cycle. Painting the DeformEffect tiles should go in the latter.
On top of the existing "Settings" group in the settings.ini file we
should have two more groups:
Environment - contains all the configuration possible through
environment variables
Debug - contains all the possible debug variables
ClutterSettings should be able to load its initial state by using
configuration files in SYSCONFDIR and XDG_CONFIG_HOME. This allows
Clutter to have a system (and user) configuration on platforms that
do not have XSETTINGS bridges.
We already have two mechanisms for controlling the font rendering
quality on a per-application basis:
• ClutterSettings properties
• clutter_backend_set_font_options()
The font flags were always a stop-gap solution, and one that tried to
simplify a fairly complex issue beyond the point of actually being
useful.
https://bugzilla.gnome.org/show_bug.cgi?id=660786
The grab API is a relic of Clutter 0.6, and hasn't been through proper
vetting in a *long* time — mostly due to the fact that we don't really
like grabs, and point to the ::captured-event as a way to implement
"soft grabs" in toolkits and applications.
The implementation of full and device grabs uses weak references on
actors instead of using the ::destroy signal, which is meant exactly for
the case of releasing pointers to actors when they are disposed.
The API naming scheme is also fairly broken, especially for
device-related grabs.
Finally, keyboard device grabs are just not implemented.
We can, in one go, clean up this mess and deprecate a bunch of badly
named API by introducing generic device grab/ungrab methods on
ClutterInputDevice, and re-implement the current API on top of them.
GLib deprecated g_thread_init(), and threading support is initialized
by GObject, so Clutter already runs with threading support enabled. We
can drop the clutter_threads_init() call requirement, and initialize the
Big Clutter Lock™ on clutter_init(). This reduces the things that have
to be done when dealing with threads with Clutter, and the things that
can possibly go wrong.
The Big Clutter Lock™ can now be a static GMutex, since GLib supports
them. We can also drop a bunch of checks given the recent changes in
GLib threading API.
