While this sounds counter-intuitive, the image-path hint value might also
be used with URIs or icon names.
As per freedesktop standard:
The "app_icon" parameter and "image-path" hint should be either an URI
(file:// is the only URI schema supported right now) or a name in a
freedesktop.org-compliant icon theme (not a GTK+ stock ID).
Thus the image-path hint should also be parsed as it happens for the
app_icon.
Reuse same logic, by falling back on _iconForNotificationData with the
hint value.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/285
cogl_texture_new() is used in a few places in GNOME Shell, but
it's a deprecated Cogl function. The replacement is the less
verbose cogl_texture_2d_new_with_size(), that is very much a
straightforward replacement.
Remove the few places where this function is used, replacing
it by the CoglTexture2d counterpart.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/287
We have a callback that will call close() when the notification is
destroyed, and a callback that will call destroy() on the notification
when the message is closed.
Currently, if the notification is destroyed we'll execute our callback
that will call again destroy() on the notification. That's bad
practice in general, and it also has the side effect of resetting the
destroy reason.
This commit avoids re-destroying the notification by dropping the
notification reference on destroy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/258
Differently from the fd.o notifications, Gtk notifications do not
have a mechanism to update themselves. Instead, when a new
notification is received for an ID already known to the notification
daemon, the old notification is dismissed and a replaced with a new
one.
Currently though, there is no way to distinguish a notification that
was dismissed because of an user interaction, or because it was
replaced. That is an useful piece of information, so add a new value
to the NotificationDestroyedReason enum to account for it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/258
StTextureCache installs file monitors that invalidate caches when
contents of the underlying file change.
At the moment, the cache uses the Gio.FileMonitorEvent.CHANGED event
type to make that determination.
However, that is suboptimal for at least two reasons:
- while a file is being written to disk, many CHANGED events will be
emitted in sequence. That will cause needless cache invalidations,
and we will risk loading the file before it's fully loaded.
- if an existing file is replaced, e.g. with g_file_replace(), we may
not get a CHANGED event but a CREATED one instead, so the cache ends
up never getting invalidated.
The good news is that in both of those cases GFileMonitor will send a
CHANGES_DONE_HINT event after changes have settled, or after the file
is replaced.
This commit fixes both cases by switching from the CHANGED event to
CHANGES_DONE_HINT to determine that a file has in fact changed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/286
When gnome-shell receives the signal of 'set-content-type' from ibus,
gnome-shell calls KeyboardManager.holdKeyboard() and
KeyboardManager.releaseKeyboard() and the functions change the current
input focus in GNOME Xorg and it could result in closing a popup window
which has a password entry by focusing on the entry.
The solution is to stop to call the APIs on 'set-content-type' signal.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/391
We don't usually show notification banners while the monitor is in
fullscreen, but when we do - the notification is urgent - we should
actually show the banner, even if the top-most window is unredirected.
To achieve that, disable unredirection while the banner is showing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/430
If the initialization fails for some reason, for example by
running 'gnome-shell --replace', we should not crash because
of an attempt of unregistering an unregistered agent handle.
Fix that by checking if the handle is not NULL before calling
the unregistering routines.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/66
The `reactive` property of icon actors was being restored multiple times
over the course of the pulse animation, all at slightly different times
as each icon finished animating at different times.
The problem is that toggling `reactive` on an `StWidget` incurs a style
change of the `insensitive` pseudo class, and style changes would quickly
queue relayouts incurring full stage reallocation. This occurred many times
during a pulse animation, limiting its smoothness and performance.
The solution is to not toggle the `reactive` property in the pulse
animation at all, which avoids incurring multiple full stage relayouts.
As a bonus, this means the icon under the cursor pulses with the correct
selection highlight, appearing more seamless and responsive.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/261
The `reactive` property of icon actors was being restored 24 times over
the course of the spring animation, all at slightly different times as
each icon finished animating at different times.
The problem is that toggling `reactive` on an `StWidget` incurs a style
change of the `insensitive` pseudo class, and style changes would quickly
queue relayouts incurring full stage reallocation. This occurred many times
during a spring animation hogging the CPU and limiting the frame rate.
The solution is defer and batch the cleanup for all icons until after the
last icon has finished animating. This way the CPU impact of the style
change and stage relayout isn't felt during the animation so the frame
rate remains higher and smoother. The overall CPU usage of the animation
is also reduced as the remaining relayouts are much more likely to be
grouped into a single frame.
Icon spring animation performance on an i7-7700:
Before: 83% CPU and 47 FPS
After : 78% CPU and 54 FPS
which is about a 22% increase in performance per clock (FPS/CPU).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/253
The switcher popup is a large, mostly transparent actor that
should cover all the clickable area of GNOME Shell. In Clutter
terms, it should cover the whole stage.
By binding it to the primary monitor, the Alt+Tab behavior
becomes a bit inconsistent. For example, by not hiding when
clicking at empty spaces at other monitors.
Fix that by binding the SwitcherPopup to the whole stage,
and not only the primary monitor.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/647
If no password or a wrong password is entered after automounting an
encrypted device, then the password should be reasked. However, this
does not happen because the relevant udisks error messages for this
cases are missing in the exception handler that calls _reaskPassword.
Fix this issue by adding the relevant udisks error strings to the
exception handling in the _onVolumeMounted method.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/640
Fix a regression causing the portal helper to crash.
In 94423151b2 we moved the dbus interface
descriptions into seperate files which is why we had to include the
fileUtils js module. This module imports the params js module, so add
params.js to the gresources file for the portal helper.
We currently only ignore minimized windows, not windows that are
hidden for other reasons - namely on wayland windows are initially
hidden until they are placed.
This fixes a flicker in the transparent top bar on wayland when the
"position" of an unplaced window wrongly suggests the window is
overlapping the top bar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/693
Since we started to show OSD windows on all monitors, OSD windows are
destroyed when the corresponding monitor is disconnected. We shouldn't
leave any signal handlers around in that case - they prevent the object
from being garbage collected, and trigger warnings for accessing proper-
ties of invalidated GObjects.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/602
When maxLevel is > 100%, first OSD appearance was capping the current
level to 100%. Consecutives key press were then OK.
Ensure we setMaxLevel before setting Level itself, so that correct cap
value is applied.
The HACKING.md file contains an enumeration in the Indentation and
whitespace section, but the sentences look incorrectly divided.
This patch proposes a fix for that section, reordering all its
contents in a single enumeration, instead of a paragraph and
an enumeration, and also reconstruct the sentences.
App folder popups take a grab when opened, and as we don't pass any
particular pushModal() parameters, all keybindings are blocked. While
this makes sense for most keybindings that would interfere with the
popup interaction, others like volume/brightness keys or screenshots
can be allowed safely.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/648
Add exception to handle a keypress if numlock is enabled as we already do for
capslock. This uses Clutter.ModifierType.MOD2_MASK because at the moment there
is not a more explicit way to refer to the numlock mask.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/550
Instead of taking care of the PanelMenu.ButtonBox.container
destruction by itself, delegate that to the very object that
created it in the first place: PanelMenu.ButtonBox itself.
According to Clutter documentation, "[…] actors implementing the
ClutterContainer interface should override the default implementation
of the class handler of this signal and call clutter_actor_destroy()
on their children."
StBin was doing that in GObject:dispose() instead. Move the child
destruction to a new ClutterActor:destroy() vfunc override.
This is the last remaining usage of Shell.GenericContainer
in the codebase, and posed small challenges compared to the
other removals.
A new St.Widget subclass called InputSourceIndicatorContainer
was added as a replacement to the Shell.GenericContainer. It
was needed because GNOME Shell needs to override the regular
size allocation functions, but InputSourceIndicator already
is a St.Widget with its own size allocation overrides.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
The test doesn't look and behave like before, but they are
already broken in master anyway. This commit makes it work
without Shell.GenericContainer, but the test itself remains
to be fixed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Because we're late in the cycle, and don't know how many
extensions actually rely on this API, this commit adds
back the BoxPointer.show() and .hide() functions, with
warning messages to notify consumers that this is going
to be removed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Pretty much like dd4709bb2, BoxPointer's show() and hide()
functions will clash with Clutter.Actor's ones.
In addition to that, on a conceptual level, the current API
is not great, because calling boxPointer.hide() won't result
in boxPointer.actor.visible == false.
For these reasons, rename show() and hide() to open() and
close(). A compatibility layer will be added in a following
commit, warning about the usage of show() and hide().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
LayoutManager is currently a pure JavaScript class that
relies on the rudimentary Signals.addSignalMethods() to
handle signals. This is an inefficient implementation of
one of the most central classes in GNOME Shell.
In addition to removing Shell.GenericContainer, then,
turn LayoutManager into a proper GObject.Object subclass.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
In the next commit, we will turn PanelMenu.ButtonBox into a
St.Widget subclass. As a domino effect, PanelMenu.Button will
become one too, and so will Panel.AppMenuButton.
When that happens, the current show() and hide() functions in
Panel.AppMenuButton will clash with Clutter.Actor's ones.
To avoid that, rename these functions to fadeIn() and fadeOut()
and avoid a name clash.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
