Since the removal of the old (pre-3.16) message tray, legacy tray icons
are very unlikely to be placed in a container that is animated using the
deprecated anchor point.
Just assume that the regular stage position is good enough.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/572
Since we started to support tray icons on wayland, the icon we show
is not the actual XEmbed window. Instead, we let mutter create a
MetaWindow for it, then use its window actor as source for a clone
we (or nowadays: extensions) can add, remove and destroy freely.
To not let the real icon get in the way, we set an empty input shape
and make its window actor fully transparent. This works OK on X11,
but on wayland all events still go through Clutter, so any reactive
surface actor inside the window actor will block events for any actors
underneath (and status icons go into the top-windows group, so almost
all actors are affected).
Luckily we can pile another hack onto the pile of status icon hacks ...
https://gitlab.gnome.org/GNOME/gnome-shell/issues/191
If a tray icon gets a mapped and unmapped and the mapped again
in quick succession, we can end up with multiple handlers
listening for window creation events.
This commit tries to guard against that by only listening for
window-created events when we don't know the actor associated
with the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=787361
After having embedded a Gtk window, we start to listen for the
corresponding MetaWindow to know when it has been mapped by the
compositor. If the embedder does not realize the window immediately,
and some other window is created and mapped before the embedder
realizes the window, we would prior to this patch try to dereference
the not created GdkWindow. Fix this by NULL checking the GdkWindow
before dereferencing. We will never miss the needed MetaWindow creation
since it can not have been mapped have it not yet been realized.
https://bugzilla.gnome.org/show_bug.cgi?id=776130
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
The current code assumes that an embedded window will correspond to
a single MetaWindow over the entire lifetime of the icon, which is
incorrect - the embedded window is unmanaged on Unmap and a new
MetaWindow will be created the next time the embedded window is
mapped. As we currently ignore the new MetaWindow completely, it
will be shown normally in the scene instead of the embedded clone
as intended.
Fix this by setting up clone and window actor each time the embedded
window is mapped rather than once in shell_gtk_embed_set_window().
https://bugzilla.gnome.org/show_bug.cgi?id=745824
The window actor shouldn't have been picked since it has an empty
input shape, but bugs in mutter weren't properly interpreting that.
Since the Wayland restructure, the MetaWindowActor isn't actually
reactive anymore, it's the MetaSurfaceActorX11, so this code isn't
doing anything.
The MetaWindowActor isn't painted, and we empty its input shape in
the X scene graph, but Clutter still picked it. Set it as unreactive
so that it can't be picked.
https://bugzilla.gnome.org/show_bug.cgi?id=706536
Otherwise they break the "top level window" detection used by the
unredirect code in mutter, causes game windows not to be unredirected
when tray icons are present.
https://bugzilla.gnome.org/show_bug.cgi?id=701224
Previously when a client requests that a window should be docked the
shell would reparent the socket window onto the stage's window and
then use ClutterX11TexturePixmap to get a texture to represent the
window. This will not work if Clutter is no longer using the X11
winsys for example if it becomes its own display server. Instead this
patch leaves the socket window as a child of the root window and lets
mutter create a MetaWindow out of it. If Mutter is acting as a display
server then this mechanism will still work via the headless x server.
The ShellGtkEmbed instance now registers for notification of the
‘window-created’ signal of the display so that it can find the
MetaWindow that gets created to represent the socket window. When this
window is found it is prevented from being displayed on the screen by
setting the actor's opacity to 0. An input shape is then set on the
window to prevent it receiving any input.
Instead of being a subclass of ClutterX11TexturePixmap, ShellGtkEmbed
is now a subclass of ClutterClone. When the MetaWindow is found for
the socket window the clone's source is set to the invisible actor for
the window so it can be displayed in the panel as before.
The ShellEmbeddedWindow no longer needs to know what the stage is
because it no longer reparents the socket window. Therefore the
ShellTrayManager doesn't need to know the stage either so
shell_tray_manager_manage_stage has been replaced with just
shell_tray_manager_manage_screen.
https://bugzilla.gnome.org/show_bug.cgi?id=693438
Clutter will try to unmap during a dispose if we have a parent, so if we
set our own actor to NULL before the chain up, we're going to attempt to
unmap our own NULL actor. Fix that by swapping the order in which we
chain up.
https://bugzilla.gnome.org/show_bug.cgi?id=672790
We used to use realize/unrealize instead of map/unmap in ShellEmbeddedWindow
because there originally was no map/unmap. The days of this are long gone...
https://bugzilla.gnome.org/show_bug.cgi?id=672790
Synchronizing the actor and window position on paint resulted in lots
of syncing, and also resulted in the window mistakenly being left at
0,0 if the actor wasn't visible when the window first mapped.
Revert back to the old way of doing it, by tying into
clutter_actor_allocate, which was only failing before because of a bug
elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=635695
Previously the code to keep the X window aligned with its actor made
various assumptions that were true in the panel status tray area but
that are not true in the message tray. Fix it up by repositioning the
X window at clutter_actor_paint() time, which will definitely be
called every time the actor moves, whether it's because of its own or
its parent/ancestor's changes.
https://bugzilla.gnome.org/show_bug.cgi?id=608869
As of 1.4, ClutterGLXTexturePixmap is identical to
ClutterX11TexturePixmap (with the differences having been moved into
the cogl layer). So make ShellGtkEmbed use the (introspected) X11
version, which then allows us to make the instance and class structs
public as well.
https://bugzilla.gnome.org/show_bug.cgi?id=608869
To replace all calls to deprecated code, GTK+ 2.20 is required - add
some basic compatibility code, so that is still possible to build the
shell with GTK+ 2.18 when not using -DGSEAL_ENABLE.
https://bugzilla.gnome.org/show_bug.cgi?id=618258
With the transition to GTK+ 3.0, direct access to struct members
will no longer be possible.
This bumps the required minimum version of GTK+ to 2.20.
https://bugzilla.gnome.org/show_bug.cgi?id=618258
- clutter_actor_get_transformed_position()/size() return floats
- clutter_stage_get_actor_at_pos() takes a pick mode
- ClutterTimeline no longer has a concept of frames
- ClutterUnit is now replaced by float
- cogl_texture_new_from_data() signature changed
http://bugzilla.gnome.org/show_bug.cgi?id=585013
* Rename ShellGtkWindowActor to ShellGtkEmbed, and make it require
a ShellEmbeddedWindow rather than a general GtkWindow.
* Add ShellEmbeddedWindow subclass of GtkWindow that bypasses most
of the GtkWindow complexity for size negotiation, and calls out
to a clutter actor instead; also automatically handle reparenting
the GtkWindow into the stage window.
* Use the reworked ShellGtkEmbed in ShellTrayManager, this simplifies
the code a bit, and more importantly results in the tray icons
having the correct size negotiation, rather than having a fixed
24x24 size.
http://bugzilla.gnome.org/show_bug.cgi?id=580047
