At the moment gnome-shell can get really confused if a menu is
fading out and gets clicked.
It can lead to mouse pointer input getting stuck until the shell
is restarted.
This commit addresses the problem by ignoring input events that
come in when the menu is closing.
The intention of commit 4dc20398 was to disable unredirection while
banners are shown, but the ::done-displaying signal currently used for
re-enabling unredirection is only emitted under some circumstances, so
it's possible that unredirection is left disabled indefinitely, whoops.
Fix this by tying disabling unredirection explicitly to the lifetime
of the banner actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/799
The only reason for `vfunc_paint` and `vfunc_pick` existing was to
implement a culling optimization. Although that optimization actually
made performance worse than none at all because it forced the painting
and picking cycles to spend more time calling into JavaScript.
Turns out we don't have to choose between native code and culling though.
Just reimplement the culling using native ClutterActor functions and we
get the benefits of both.
Performance on an i7-7700:
Moving the cursor over the icon grid:
Before: 70% CPU, 5.5ms per frame
After : 60% CPU, 4.5ms per frame
Scrolling the icon grid:
Before: 60% CPU, 4.4ms per frame
After : 50% CPU, 3.3ms per frame
Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/174
Destroy the DashItemContainer's child from the same handler as the tooltip. This
will prevent invalid reads when the item is destroyed while its quicklist is
still open.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/781
Back in the day, there was a proposed system of tracking apps in a
specific context.
The inspiration was that you may have used apps in multiple modes:
Firefox may have been used in both "Programmer Reference" and
"Kitten Videos" contexts. Early user response to the feedback wasn't
too positive - context switching is something that humans have trouble
doing implicitly, let alone explicitly. The old codebase still has a
few remnants of this around; let's finally put them to rest.
Note that we still write out a dummy context tag to the XML file - old
versions of the shell will flat out crash if you don't have one of those
in there, so just leave it in for compatibility sake.
https://bugzilla.gnome.org/show_bug.cgi?id=673767
The pending-charge state means AC power is on but the battery is not
being charged. This can happen because its charge is above a certain
threshold, to avoid short charging cycles and prolong the battery's
life, or because the PSU is not powerful enough to charge the batteries.
Instead of lying to the user about something being estimated, we should
simply tell the truth and set the label to "Not Charging".
Closes: #701.
When we started to only show a single caption at a time, we allowed
title captions to be wider than their corresponding window preview.
But while overlapping neighboring previews is fine, we shouldn't
allow the captions to leak outside the workspace area itself and
overlap unrelated elements like workspace switcher or dash.
This partly reverts commit b3b30f239d.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/214
Instead of defaulting to a natural scroll behavior,
have the workspace switch action use the natural-scroll setting
in org.gnome.peripherals.touchpad to determine the correct
direction of travel when swiping. 4 finger swipes will then
match the behavior of the rest of the UI.
Reference: https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
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
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
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
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
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.
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.
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
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
This is another straight port from Shell.GenericContainer.
The important thing to notice is that the calculation is
broken if the StThemeNode helpers (adjust_preferred_* and
adjust_for_*) aren't used.
The downside of this patch is that it removed the skip_paint
from the thumbnails. Keeping it would add an unecessarily
large amount of code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Removing Shell.GenericContainer from the IconGrid class was
challenging because it needs the "skip paint" API from it.
This API was added, too, as a workaround to the inability
to override vfuncs from GJS.
The overrides are largely copy-pasted and translated versions
of the Shell.GenericContainer code.
The IconGrid:key-focus-in signal was renamed to :child-focused
to avoid clashing with ClutterActor:key-focus-in.
In GridSearchResults, the internal IconGrid had it's y_expand
set to false, so it doesn't push other search elements (the
list results mainly) to the bottom of the screen.
Because skip paint wasn't and still isn't a GObject property,
rename it to _skipPaint to reflect that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
As part of our quest to obsolete Shell.GenericContainer, IconGrid will
become a Clutter.Actor subclass. As the ::key-focus-in signal would
clash with Clutter.Actor::key-focus-in, rename it to ::child-focused.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
