The Mutter plugin manager has now been changed so that it itself will
pass on the events through Clutter so there is no need to do this in
Gnome Shell anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
shell_app_compare() (which is only used as sort function for
shell_app_system_get_running() nowadays) currently takes the
visibility of an app's windows into account, e.g. applications
with visible windows (non-minimized windows on current workspace)
sort earlier than applications without.
This translate traditional window-switcher behavior to applications,
but we stopped sorting by workspace in the app-switcher a while ago,
and with the new auto-minimization behavior of fullscreen windows
it is more confusing than helpful - in fact, since mutter commit
7e61ef09369a we no longer do this for the window list, so it
makes sense to apply the same to application sorting.
https://bugzilla.gnome.org/show_bug.cgi?id=707663
In specific cases, GTK+ does not have enough information to set a correct
opaque region, in which the recommended fix is to set your window as
app-paintable. In the tray icon case, the socket window was considered
opaque but GTK+ as it had a solid window background, but it cannot have an
opaque region set, as the plug isn't composited against the socket, but
instead punches through the socket window.
https://bugzilla.gnome.org/show_bug.cgi?id=707614
Using the same idea that shell-generic-container. It implements
AtkValue with a dummy implementation based on signals. Javascript
code would connect to that and returns the proper value.
https://bugzilla.gnome.org/show_bug.cgi?id=648623
In the common case, the accessible object is created by the
own widget. In some cases it is needed to specify a custom
accessible, as some of the logic will be implemented on the
javascript code (extend functionality using Components vs Hierarchy).
https://bugzilla.gnome.org/show_bug.cgi?id=648623
Build gnome-shell for x11, and gnome-shell-wayland for wayland
(as well as the associated libgnome-shell and libgnome-shell-wayland).
The first one links to libmutter, the second to libmutter-wayland.
libgnome-shell and libgnome-shell-wayland are now compiled from
libgnome-shell-base (with all sources that are independent of mutter),
libgnome-shell-menu (with the copy-pasted gtk sources), plus the
sources that use mutter API
https://bugzilla.gnome.org/show_bug.cgi?id=705497
It's mostly equivalent to "jhbuild run gnome-shell", which is
the preferred way. Also, running from the source tree can't be
supported at this point, and the wrapper is getting in the way
of having two binaries, one for wayland and one for X11.
https://bugzilla.gnome.org/show_bug.cgi?id=705497
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
Ever since we stopped reparenting status icon windows to the stage, tray icons
haven't been inferiors and thus we don't have to filter out enter/leave events
for them, as we never show them outside of a modal.
https://bugzilla.gnome.org/show_bug.cgi?id=706536
Unfortunately, display configuration can and does fail, due
to unspecified HW constraints, drivers bugs, unsupported exotic
configurations or just bad luck.
So when the user makes a change in the control center, show
a dialog asking him if it looks OK, and revert back after 20 seconds
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=706208
With StBoxLayout using the Clutter layout manager, it will now respect
actors' expand/align properties. However for the change to be transparent,
we need to support the existing child meta properties as well. Do
this by simply translating them to the corresponding ClutterBoxChild
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=703810
With the BoxLayout containers in St and Mx and the ClutterBoxLayout
manager, we now have three more or less diverged implementations of
the same layout policy.
While removing StBoxLayout entirely in favor of ClutterLayoutManager
would be the fashionable thing to do, there are obvious drawbacks:
- it is the only actor we have that implements the scrollable interface
- it conveniently exposes its spacing property in CSS
- last but not least, it is used all over the place
So do the next best thing and make our implementation use the
Clutter layout manager internally - that way, the change is
transparent to users, while we get to refer most of the tricky
bits to Clutter. win-win!
https://bugzilla.gnome.org/show_bug.cgi?id=703810
Replace more direct XFixes usage with a the appropriate abstraction
API from mutter, which is guaranteed to work in wayland too.
It doesn't yet replace pointer position tracking, although probably
it should.
Also, because now we're using Mutter API, we lose the standalone
test case.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Mutter now includes an object with the same purpose and functionality
as ShellXFixesCursor, so we can replace our XFixes code with it
and work under wayland too.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
In the new application model, there is one ID shared by GApplication,
DBus and .desktop files, so we can use that for the association,
instead of fiddling with badly cased wm classes.
https://bugzilla.gnome.org/show_bug.cgi?id=706252
This is needed to handle applications that are converted to
reverse dns notation, if their application ID includes capital
letters (as it is often the case for DBus names)
https://bugzilla.gnome.org/show_bug.cgi?id=706252
This will replace the indicator painted on the stage right now.
This unfortunately does not work for the recorder triggered by the
keybinding -- we'll simply replace the in-shell code with a keybinding
powered by gnome-settings-daemon.
Commit cfecd063c9 changed the allocation logic to not allocate
scrollbars when the *_visible booleans are false. This breaks the
fade effect as well as the NEVER policy. We do not paint scrollbars
when they are not supposed to be visible, so not allocating them
and thus leaving them in a "needs allocation" state just causes problems.
I am not convinced that it solved any problem to begin with (we don't paint
them anyway).
As the previous condition has basically always been true, just do it
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=705664
Chromium (but not google-chrome) has a StartupWMClass in the desktop
file, so we must match the instance part first to have chrome
web apps working.
Also, we must take care of apps without a wm_class or instance at
all.
https://bugzilla.gnome.org/show_bug.cgi?id=673657
Some applications (such as most Java apps, as well as Chrome Web apps) ship
with desktop files that have the wrong name, but whose StartupWMClass
field contains the right value. Therefore first check that key, against
both the class and instance part of WM_CLASS, and only use the filename
if nothing else works.
https://bugzilla.gnome.org/show_bug.cgi?id=673657
The point of fading the icon is to make the text displayed over the
icon more legible. In RTL layouts, the text is displayed on the left
of the icon, so fading the right-hand-side of the icon doesn't work
well.
https://bugzilla.gnome.org/show_bug.cgi?id=704583
We don't set :visible on the scrollbars, but use booleans to track
if they are visible. Thus check the booleans instead of the actor's
properties when allocating the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=704265
