Creating a new GTimeZone for the local timezone can be quite expensive if
done repeatedly. It requires an open(), mmap(), and parsing of
/etc/localtime.
This patch was provided by Florian, and I've tested it as far back as
3.28.4 to ensure that we are really reducing the number of open() calls
on the compositor thread.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1051
Signed-off-by: Christian Hergert <chergert@redhat.com>
# Conflicts:
# js/ui/environment.js
The g_file_replace_contents_async() API can potentially call fsync() from
the thread calling into it upon completion. This can have disasterous
effects when run from the compositor main thread such as complete stalls.
This is a followup to 86a00b6872 which
assumed (like the rest of us) that the fsync() would be performed on the
thread that was doing the I/O operations.
You can verify this with an strace -e fsync and cause terminal to display
a command completed notification (eg: from a backdrop window).
This also fixes a lifecycle bug for the variant, as
g_file_replace_contents_async() does not copy the data during the operation
as that is the responsibility of the caller. Instead, we just use a GBytes
variant and reference the variant there.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1050
This is an expensive operation that is best avoided in the main loop. Given
the call doesn't care much about returning error or status, it can just
be made async within.
Every operation on a given file will be destructive wrt previous
operations on the same file, so we just cancel any pending operation on
it before batching the current one.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/815
Conflicts:
src/shell-global.c
Whenever an app is installed, the usual routine is
to run 'gtk-update-icon-cache' after installing all
of the app's files.
The side effect of that is that the .desktop file of
the application is installed before the icon theme
is updated. By the time GAppInfoMonitor emits the
'changed' signal, the icon theme is not yet updated,
leading to StIcon use the fallback icon.
Under some circumstances (e.g. on very slow spinning
disks) the app icon is never actually loaded, and we
see the fallback icon forever.
Monitor the icon theme for changes when an app is
installed. Try as many as 6 times before giving up
on detecting an icon theme update.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/661
Calls to Gio.AppInfo.get_all() can perform quite a bit of I/O on the
calling thread. This can potentially stall the compositor if the disk
controller is saturated.
Instead we can call the new ShellAppCache which contains cached information
and performs all update I/O on a thread.
Notifications of changes work very similar to GAppInfoMonitor via the
ShellAppCache::changed() signal.
This was performing quite a bit of I/O on the main thread previously. Now,
all the I/O is deferred to a worker thread and the translated names are
cached for immediate lookup.
A number of things can result in doing I/O on the main thread such as
loading GAppInfo or folder translations. The ShellAppCache provides a
layer of abstraction around those things so that we can keep that work
off the main thread by delaying a short while and processing the work
synchronously off-main-thread.
The results can then be marshalled back to the main thread for use by
the rest of the system via the ShellAppCache::changed() signal.
This ensures that we do not create a new GTimeZone with
g_time_zone_new_local() repeatedly. Currently, that will cause GTimeZone
to open(), mmap() and parse /etc/localtime while on the main thread.
We already track timezone changes, so we can cache this value and reuse
it if we:
1) Clear the cache when timezone changes
2) Use the only GDateTime API available to us here, which means we
imply the current time. But this is how environment.js uses the
date and time anyway, so no loss.
We maintain the old form for plugin compatibility.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2279
All adjustment setter functions take good care of avoiding emission of
notify:: when it's not needed. The set_property() implementation already
calls into the setter functions, so mark the properties as EXPLICITY_NOTIFY
in order to optimize notify:: emission away through g_object_set (rather
common from JS code).
(cherry picked from commit b1b455ff1a)
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1270
Dialog's subtitle or body could not be properly wrapped, while it's ellipsized
when the text's width doesn't exceed the container size.
Clutter text has an `ellipsize` property, however in dialog's subtitle and body
we have been setting the `ellipsize-mode` property to Pango.EllipsizeMode.NONE
that is not present in the underlying GObject.
Not being an error in javascript, gjs didn't warn us about this, while at the
same time the St.Label's default Pango.EllipsizeMode.END was used.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/922https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/531
(cherry picked from commit 3121c9aa29)
On X11, reactive chrome must be added to the input region in order
to work as expected. However that region works independently from
any window stacking, with the result that the unresponsive-app dialog
currently blocks all input in the "covered" area, even in windows
stacked above the unresponsive window.
The correct fix would be to track the unobscured parts of the dialog
and set the input region from that, but that's quite cumbersome. So
instead, only track chrome when the corresponding window is focused
(or the dialog itself of course).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/273
The close dialog for non-responding windows is closed automatically
when we detect that the window is responding again. However as we
currently only ping the window in response to certain user actions
(like focusing the window or opening the window menu), this can
easily go undetected.
Address this by periodically pinging the window while the close
dialog is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
The dialog won't be visible when unredirection is in place (for example
while a fullscreen window is focused), so disable unredirection while
the dialog is up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
Since commit 551e827841, we don't always pass a callback parameter.
However passing it on as undefined to ibus doesn't work, as gjs doesn't
accept that as a valid callback value and throw an error. As a result,
we can end up with no layout selected in the keyboard menu and an "empty"
indicator. Fix this by explicitly passing null if no callback has been
provided.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/293
(cherry picked from commit 74bb9e6249)
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.
(cherry picked from commit b719744e75)
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
(cherry picked from commit 551e827841)
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
(cherry picked from commit e5ce3d541e)
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
(cherry picked from commit 4dc2039859)
This attribute was previously only assigned in show(). hide() compares
this attribute to 0. If hide() is called before show() is first called,
the comparison would give the correct result (undefined > 0 is false)
but log a warning:
JS WARNING: [resource:///org/gnome/shell/ui/workspacesView.js 529]:
reference to undefined property "_restackedNotifyId"
Initialize this attribute in _init(), alongside _scrollEventId and
_keyPressEventId which are also used in hide().
(cherry picked from commit b2fabd9356)
dialogContent is set to one of the elements of the list DialogContent,
but not all of those have a checkBoxText property. When logging out (as
opposed to shutting down), this causes a warning:
JS WARNING: [resource:///org/gnome/shell/ui/endSessionDialog.js
763]: reference to undefined property "checkBoxText"
(The line number corresponds to this line in 3.28.3.)
The warning is apparently not triggered if the undefined property is
used as part of a boolean expression:
gjs> var x = {};
gjs> x.a;
typein:2:1 strict warning: reference to undefined property "a"
gjs> if (x.b) { log('oh no'); }
gjs> x.c || ''
""
_setCheckBoxLabel() just checks the truthiness of its 'text' argument,
and the empty string is false-y, so passing '' rather than undefined has
no functional effect.
(cherry picked from commit 0892b5dcdb)
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
(cherry-picked from commit a0dc8dc7ef)
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
(cherry picked from commit 33b8537bf5)
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
(cherry picked from commit ff2fbf5ae4)
If the actor is not on the stage yet (i.e. does not have a theme
node), but has a paint state cached, we currently fail to invalidate
it, which will lead to the actor painting with old contents once it
gets onto the stage.
This commit fixes the issue by changing our invalidation strategy;
previously we were looking at the widget's own theme node to determine
if it should be invalidated or not.
Now we look at the theme nodes of our cached paint states. When the
widget is mapped on stage, those are the same as the widget's own
theme node, but when the widget is not on the stage, we'll still be
able to invalidate them.
As part of this, we move the invalidation API to StThemeNodePaintState,
which is a more natural place for our use case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/314
(cherry picked from commit 6743c18fdf)
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
(cherry picked from commit ca3f4cfb41)
When computing the effective border color, we operate on colors with
premultiplied alpha to simplify the calculations, then unpremultiply
the result. However we miss a bounds check in the last check, so any
color component can overflow the allowed maximum of 0xff and shift the
result in unexpected ways.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/305
(cherry picked from commit 925a25da17)
The picked target actor may be destroyed (e.g. hover style change
resulting in the ClutterTexture to be destroyed). If we don't handle
this, GJS will abort when it sees the exception caused by Javascript
code trying to access the destroyed target actor.
To handle it, listen on the 'destroy' signal on the target actor, and
repick, so a valid actor is passed to the next motion callback.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/632
(cherry picked from commit 4259676f6e)
In X11, pointer emulated touch events are replicated with normal PRESS, RELEASE
pair events which are generated by the server. Thus for a single tap we get:
- TOUCH_BEGIN -> TOUCH_END, PRESS -> RELEASE
This will cause st-button to send two "clicked" signals, instead of just one,
breaking extensions (like dash-to-dock) that show buttons in the main stage
which will be checked two times or that will receive the same signal two times.
(cherry picked from commit 4c11d15a07)
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
(cherry picked from commit a5e6dd52d2)
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
The _sync function for Message only updates the close button visibility,
so we can safely stop doing that if the close button get get destroyed earlier
(as it happens when clicking on it).
https://bugzilla.gnome.org/show_bug.cgi?id=791233
(cherry picked from commit 87da623d86)
If the volume is removed before AUTORUN_EXPIRE_TIMEOUT_SECS seconds, we can stop
the timeout earlier as there's nothing to unset, while the volume instance
won't be valid anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
(cherry picked from commit 9c41736a81)
