Rather than scanning all apps for searching, use Ryan's new desktop
file index and the glib support APIs for app searching instead of our
own system.
https://bugzilla.gnome.org/show_bug.cgi?id=711631
While unfortunate that we still have to scan all apps with get_all(),
support for this feature will be short-lived, so hopefully we can drop
it in the future as new apps adapt to the desktop file / app ID
recommendations.
For now, simply scan all desktop IDs.
https://bugzilla.gnome.org/show_bug.cgi?id=711631
Systemd-for-the-user-session would also do this, but that's a deeply
invasive change that I may not actually get to this cycle. This
change is tiny and non-invasive, but provides an important benefit:
You can actually reliably tell *which* applications are logging which
messages (assuming they're launched by the shell).
This actually complements a recent change in DBus:
See https://bugs.freedesktop.org/show_bug.cgi?id=68559
which does a similar thing for bus activated apps.
https://bugzilla.gnome.org/show_bug.cgi?id=711626
Rather than create all ShellApps up-front, create them lazily. We really
had no reason to do this before as we were scanning GMenu to get all the
apps, but doing this can remove a need for get_all, which is slow and
memory-hungry.
We want to transition to a system in the future where we have a desktop
file cache. As we no longer differentiate categories or similar, it no
longer makes sense to have app visibility based on categories. Thus,
we no longer need to use gnome-menus to list all apps. The potential
issue here is reloading all desktop files when new files are created,
but this can be dealt with individually.
The "All Applications" view still uses gnome-menus.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
Since appDisplay.js makes its own GMenu tree, it's not necessary
anymore. This does mean that searches will show apps in NoDisplay
categories, but that's an obscure enough edge case not to matter.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
This does remove support for legacy prefixed app infos with
subdirs, but since we want to remove support for the menu spec,
let's not even bother.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
It's a broken method when it comes to giving us a useful GDesktopAppInfo,
and it's hard to fix libgmenu properly, so simply recreate the app info
using the desktop file ID that libgmenu has.
We want to move away from gnome-menus eventually, so the simple
utility method isn't really worth keeping around. Reimplement it
in the one place that uses it.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
In cases where we have an array of 0 elements or similar, the
data returned may be NULL. Since g_file_replace_contents will
assert in this case, simply check for this and delete the file
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
gcr/gnome-keyring don't handle the case where prompt_password_async()/
prompt_confirm_async() return their result from within the function
very well (or rather: break badly). Calling gcr_prompt_close() instead
is safe, but to avoid these kind of errors in the future, modify
shell_keyring_prompt_cancel() to work as expected in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=708187
Commit 4095a58eb9 introduced a
regression, since we have to take into account four cases,
top, bottom, right, and left, and that can't be merged into
two like that commit did.
So fix it to make fade effect works again.
https://bugzilla.gnome.org/show_bug.cgi?id=708256
The vvalue and hvalue uniforms are only used to decide whether we
should do fade the edges or not based on the fade_edges uniform.
The result does not change accross fragments so there is no reason
to recompute it for every fragment (pixel) so just split the edge
fade into two uniforms and compute the "should we fade the edges"
boolean once for every direction (when setting the uniforms) instead
of for every single fragment twice.
This reduces the number of uniforms as well as the the number of instructions
which are limited on older hardware. It should also be more efficent.
https://bugzilla.gnome.org/show_bug.cgi?id=708007
Gdk uses Xwayland, so it only sees the events we forward to X11
clients. Instead, we can use the abstraction API provided by
mutter and get the right value automatically.
Also, we need to use MetaCursorTracker to handle the cursor
visibility too.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
We need to call into MetaScreen to set the cursor, but we can't
do that from libst, so add a hook that libgnome-shell can fill,
and remove more ClutterX11 usage.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
When running as a wayland compositor, the clutter stage doesn't
have an usable window for IPC, so just create another one.
Also, disable freezing the keyboard when running on wayland, as
we can't do it really.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
It is expected that the primary and secondary icons in entries
change places in RTL locales. When doing so, the edit-clear
icon must be replaced by an rtl variant too.
http://bugzilla.gnome.org/show_bug.cgi?id=705779
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
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
When the St theme is changed, the StThemeContext unrefs all the theme
nodes cached in it's internal hash table, then emits a signal to
notify all theme nodes that the current theme has changed.
The problem is that the first StWidget to catch a theme changed signal
will trigger a "style-changed" signal catched by its children first.
So the theme changed signal can't be processed properly to cleanup
StThemeNodePaintState before recomputing the theme.
This patch adds a weak ref to the StThemeNode in the
StThemeNodePaintState to ensure paint states are properly cleaned up
when the associated StThemeNode is freed.
https://bugzilla.gnome.org/show_bug.cgi?id=703859
Commit 318283fc70 optimized box-shadow rendering by not recreating
shadow materials on every allocation change. Other handles cannot
be reused and are updated regularly, however the patch missed the
cached corner materials - while those can be reused, we still need
to ensure that the currently used paint state references them.
https://bugzilla.gnome.org/show_bug.cgi?id=703909
It is the job of layout containers to arrange their children; having
a hidden feature that *also* allows children to be positioned freely
outside the parent's allocation is just odd.
With the last user of the feature gone, kill it.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Currently the box-shadow is rendering is done like this :
The first time we want to render a node that requires a box-shadow, St
creates an cogl offscreen surface of the size of the allocation and
renders the box into this offscreen buffer using modulation on the
alpha channel, this buffer is then blurred according to the CSS
parameters.
The problem with this method is that every time an StWidget is
resized, its box-shadow offscreen buffer has to be resized and
therefore rendered and blurred.
This patches propose an optimization for this use case by rendering
the box-shadow only once but at a size that is independent of the
StWidget's size. Then every time we need to paint this box-shadow, we
just render this offscreen buffer using a 9-slices.
This method only works when the allocation of the widget is bigger
than the minimum shadow size on which we can apply a 9-slices, that is
given my the radius of the corners. If the allocation is smaller than
this minimum size, we then fallback to the fully render/blur the
shadow (like before this patch).
https://bugzilla.gnome.org/show_bug.cgi?id=689858
The duality of the Clutter's key focus and mutter's window focus has long been
a problem for us in lots of case, and caused us to create large and complicated
hacks to get around the issue, including GrabHelper's focus grab model.
Instead of doing this, tie basic focus management into the core of gnome-shell,
instead of requiring complex "application-level" management to get it done
right.
Do this by making sure that only one of an actor or window can be focused at
the same time, and apply the appropriate logic to drop one or the other,
reactively.
Modals are considered a special case, as we grab all keyboard events, but at
the X level, the client window still has focus. Make sure to not do any input
synchronization when we have a modal.
At the same time, remove the FOCUSED input mode, as it's no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
This causes a debug SpiderMonkey build to fail when it throws an
exception for the missing symbol, but doesn't properly return FALSE
when executing the script.
https://bugzilla.gnome.org/show_bug.cgi?id=703442
While it is obviously still an error to call get_theme_node() on a
widget that hasn't been added to the stage hierarchy yet, asserting
on it hasn't proven too successful in avoiding those errors - it's
likely the most frequent reason for crash reports. Just accept that
there'll always be code paths where we can hit this case and make
it non-fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
We will allow to use mode-specific overrides; in preparation for that,
move the code so that we only override preferences after initializing
the session mode.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
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
Currently we simply set the gsettings key when activating an input
source. This obviously introduces a time window, between the event that
activates the switch and when the switch is complete, under which key
events are being delivered to applications and interpreted according
to the previous input source.
The patches in bug 696996 introduce a DBus API in g-s-d that allows us
to know when an input source if effectively active. Using that and
freezing keyboard events in the X server until we hear back from g-s-d
we can ensure that events won't be misinterpreted after an input
source switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697007
As with the screen recorder, the magnifier already adds its own
copy of the system cursor, so we should not add it again. Just
as in the screen recorder case, we don't address the case where
the cursor should not be included in the screenshot, but the
magnifier adds it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=700488
The magnifier adds its own copy of the system cursor to apply the
expected transformations, so we don't need to add it again in the
recorder; this avoids two different cursors showing up in recordings,
but doesn't address the case where the cursor should not be recorded
at all, but the magnifier adds it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=700488
It looks a bit unpolished to overlap our own chrome with the recording
icon, which may happen when an existing adds UI at the bottom edge.
Fix this by using the primary monitor's workarea for the position rather
than the entire monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=700409
Attaching gdb and running with G_DEBUG=fatal-warnings is not a very
fast to debug a specific issue (especially if you have warnings at
startup, since then you need to run the shell from a terminal).
Instead, introduce a new SHELL_DEBUG environment variable that can
be set to backtrace-warning, causing a gjs_dumpstack() after every
warning or critical.
https://bugzilla.gnome.org/show_bug.cgi?id=700262
Wrap new GtkMenuTracker API that adds an easy way to bind to
tracker items, and use it to add back support for submenus.
This also adds support for a submenu feature that we didn't
have support for before, action namespaces.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
This pulls in new upstream API that Ryan will maintain, removing
code on our side.
Currently, our implementation of submenus will be gone, but this
will be fixed in a few commits.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
We'll need some of these pieces to be introspectable when we port to
GtkMenuTrackerItem. Due to technical limitations in introspection, we
can't put Gtk-prefixed items in the shell namespace, so add them to
a new introspection library instead.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
This is a hack we have in our local fork as compared to upstream;
work on a generic "hook" system in here is ongoing, but until then,
this is the easiest way to do it.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
This includes a rename from the G* namespace to the Gtk* one, which
will help us with introspecting this code. Note that this removes
some of the custom code we added to GActionMuxer to relay event times
to the remote action group. We'll add this back soon.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
