The hierarchy handling is handled in the shell by adding stuff
directly to the uiGroup, and we have a dedicated actor for
the overview there, so we don't need this anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
Make it a static function for now, but this will be a private
function soon, replacing meta_window_lost_focus. This should
contain no functional changes, only cosmetic indentation changes,
so best viewed with ignorews=1 or -w or -b, you know the drill.
https://bugzilla.gnome.org/show_bug.cgi?id=647706
If this happens, XRRGetScreenResources will return NULL, so just treat
that like nothing happened.
https://bugzilla.gnome.org/show_bug.cgi?id=699431
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 57a79912ac70080a2f9cbe65181a25b00bf1192a)
This makes sure we include cogl-defines.h in cogl-matrix.h before
checking if COGL_HAS_GYPE_SUPPORT is defined
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit aa5ba324bb3b2ce77be29942f8716d61919cefeb)
When using a ClutterOffscreenEffect, the size of the offscreen buffer
allocated to perform the effect is currently computed using the paint
volume of the actor it's attached to and in the case the paint volume
cannot be computed, the effect falls back to using the stage's size.
If you scale an actor enough so its paint volume is much bigger that
the size of the stage, you can end up running out of memory (which
leads to your application crashing).
https://bugzilla.gnome.org/show_bug.cgi?id=699675
Clients using _NET_WM_MOVERESIZE to start a drag operation may encounter
a race condition if the user presses and releases a mouse button very
fast, getting "stuck" in a grab state. While this is easily fixed with
the user pressing the button or hitting Escape as the EWMH spec suggests,
its's still a bit of annoyance for users.
After starting a grab operation, check that the button is actually pressed
by the client, and if not, cancel the grab operation. This prevents the
stuck grab in a race-free way, although it requires an extra round-trip
to the server.
With client-side decorations becoming more popular, the use of
_NET_WM_MOVERESIZE is on the rise, thus this bug is seen more frequently
than before.
https://bugzilla.gnome.org/show_bug.cgi?id=699777
As we only had one string-array preference so far, we didn't bother
with adding a generic way to handle string-array preferences, and
just handled the preference in question explicitly. However we are
going to parse another string-array setting, so generalize the
existing code to make it reusable for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=700223
Since 906e1b5eb535a86 Cogland no longer redraws constantly but instead
only draws once at startup and then again whenever a client attaches a
new buffer. Sometimes however it seems that the first paint will get
lost perhaps because it is sent before the window is fully mapped. As
it was previously not handling expose events it would not paint again
until the first client is connected so there would be a blank window
which looks broken.
This patch makes it handle Expose events when it detects that Cogl is
using an X backend. On other backends it will resort to queuing a
redraw every 16ms as it did before.
Although this is probably a bit overkill for such a small example, it
seems like a good idea to only redraw when we think it's necessary so
that we can be sure that the mechanism works. Handling the expose
events means we can have at least one platform where we can test this.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 99cf15b285302243395873d78f05a5895c173eef)
Previously if a client sent a commit message without attaching a new
buffer then it would end up detaching the existing buffer because
surface->pending.buffer would be NULL. This patch makes it explicitly
track when an attach is sent for a commit and so that it can avoid
making any changes otherwise. This fixes cases where GTK apps would
send a damage event without a new buffer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit aa412b9c709120bd8d88a014010c448f3b9fcfb7)
The "should this implicit transition be skipped" check should live into
its own function, where we can actually explain what it does and which
conditions should be respected.
Instead of just blindly skipping actors that are unmapped, or haven't
been painted yet, we should add a couple of escape hatches.
First of all, we don't want :allocation to be implicitly animated until
we have been painted (thus allocated) once; this avoids actors "flying
in" into their allocation.
We also want to allow implicit transitions on the opacity even if we
haven't been painted yet; the internal optimization that we employ in
clutter_actor_paint() and skips painting fully transparent actors is
exactly that: an internal optimization. Caller code should not be aware
of this change, and it should not influence code outside of ClutterActor
itself.
The rest of the conditions are the same: if the easing state's duration
is zero, or if the actor is both unmapped and not in a cloned branch of
the scene graph, then implicit transitions are pointless, as they won't
be painted.
https://bugzilla.gnome.org/show_bug.cgi?id=698766
This should actually ensure that the calculations of the Z translation
for the projection matrix is resolved to "variable * CONSTANT". The
original factors are left in code so it's trivial to revert to the
trigonometric operations if need be, even without reverting this commit.
The ClutterActor::paint signal is deprecated, and connecting to it even
to get notifications will disable clipped redraws because of violations
of the paint volume.
The only actual valid use case for notifications of a successful frame
is on the ClutterStage, so we should add new (experimental) API for it,
so that users can actually subscribe to it — at least if you're writing
a compositor.
Shoving a signal in a performance critical path is not an option, and
I'm not sure I want to commit to an API like this yet. I reserve the
right to revisit this decision in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=698783
Currently, clutter_canvas_set_size() causes invalidation of the canvas
contents only if the newly set size is different. There are cases when
we want to invalidate the content regardless of the size set, but we
cannot do that right now without possibly causing two invalidations,
for instance:
clutter_canvas_set_size (canvas, new_width, new_height);
clutter_content_invalidate (canvas);
will cause two invalidations if the newly set size is different than
the existing one. One way to work around it is to check the current
size of the canvas and either call set_size() or invalidate() depending
on whether the size differs or not, respectively:
g_object_get (canvas, "width", &width, "height", &height, NULL);
if (width != new_width || height != new_height)
clutter_canvas_set_size (canvas, new_width, new_height);
else
clutter_content_invalidate (canvas);
this, howevere, implies knowledge of the internals of ClutterCanvas,
and of its optimizations — and encodes a certain behaviour in third
party code, which makes changes further down the line harder.
We could remove the optimization, and just issue an invalidation
regardless of the surface size, but it's not something I'd be happy to
do. Instead, we can add a new function specifically for ClutterCanvas
that causes a forced invalidation regardless of the size change. If we
ever decide to remove the optimization further down the road, we can
simply deprecate the function, and make it an alias of invalidate()
or set_size().
g-ir-scanner will emit more warnings regarding broken GTK-Doc
syntax in the near future, which due to --warn-error being used
would break the build:
'''
ui/theme.c:1883: Warning: Meta: missing ":" at column 20:
* @tokens_p: (out) The resulting tokens
^
g-ir-scanner: compile: gcc -Wall -Wno-deprecated-declarations ...
g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC gcc ...
libtool: link: gcc -o /home/dieterv/gnome.org/checkout/mutter/...
<unknown>:: Fatal: Meta: warnings configured as fatal
<unknown>:: Fatal: Meta: warnings configured as fatal
make[4]: *** [Meta-3.0.gir] Error 1
'''
https://bugzilla.gnome.org/show_bug.cgi?id=699636
Initial stage of ClutterPath migration to using float.
Naive implementation of ClutterBezier, for now the points along
the curve doesn't move at a regular speed. It is required a more
precise calculation of the length of the curve for that to happen.
Anyway the old implementation worked like this.
