If a process associated to an application declaring StartupNotify=true
in its desktop file exits before having ever mapped a top level window,
the "remove" X message expected as per the Startup Notification Spec [1]
won't ever be issued, and the shell will keep waiting for a while until
the sequence is finished on time out.
This provides a confusing and bad experience since things like a confusing
icon + a spinner, or the mouse pointer switching to a spinning cursor, will
be showing up in the meantime, so we need to detect those situations and
make sure the sequence gets completed, and the app moved to STOPPED.
[1] https://www.freedesktop.org/wiki/Specifications/startup-notification-specCloses: #267
We need to provide a wrapper for sn_startup_sequence_complete() from libsn,
so that's there's a way to make sure that the startup sequence gets always
finished, even if the launched process exits early without an error code
before ever having mapped a top level window (i.e. gnome-control-center).
Closes: #267
While the libnm-glib version of the function returns a GByteArray*
that gjs can directly cast to the required gutf8*, the libnm function
returns GBytes* from which we need to explicitly fetch the data.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/136
commit 642107a2 attempts to avoid resetting the current keymap on
spurious input source changes.
It does this by checking if the current layout id is found in
the new list of layouts and resetting the current layout to the
associated match in the list. By not nullifying the current
layout, it won't get subsequently reset.
Unfortunately, if the order of the list changes, resetting the
current keymap is still necessary, since the order corresponds
with the index of the activated group.
This commit changes the code to nullify the current layout if
its group index changes.
https://bugzilla.redhat.com/show_bug.cgi?id=1573923
The gnome-shell-calendar-server calls to refresh queries even when it
has no time range set, which results in:
a) waste of resources (for example after login),
b) many runtime warnings in the journalctl log, related to
incorrect time range being used.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/244
While it is theoretically fine to run --perf=hwtest without passing --hwtest,
the test will hang in this case because it fails to start gedit. Always append
Gedit to the default value for --extra-filter when running the "hwtest" test
to make it work fine without --hwtest.
The IM can pretty much update the input sources anytime (even if
to set the same ones). That ends up triggering rebuilding all user
defined keymaps, and losing modifier state if we are unfortunate
enough that this caught us while pressing one.
One common situation seems to be password entries, resulting in
the wrong character being printed if the first character happens
to require the shift key.
If the current keymap is not found in the newly loaded list,
this._current will end up null, with the same behavior as we get
currently (immediate keymap reload).
https://bugzilla.redhat.com/show_bug.cgi?id=1569211https://gitlab.gnome.org/GNOME/gnome-shell/issues/240Closes: #240
Commit f285f2c6 changed Scripting.createTestWindow() to accept a parameter
object instead of a parameter list but forgot to remove the width and height
arguments. This breaks the "core" test as all windows are created with default
settings.
We use the close() method to disconnect signal handlers set up in
init(), however the handler ID is only valid in the first call in
case the method is called more than once.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/221
If we get an error during device enrollment, the message might be
prefixed to indicate that the error came from the remote peer. We
are presenting that message to the user so strip that prefix away
if it was there.
The devices emitted (device, error) while the connected handler
was expecting (error, device). The former is more consistent
with the rest of the code (so change it to device, error).
* Remove tiny padding of user-list
* Less space between avatar and username
* Apply the 1em padding only to the user-widget, not the timed-login-indicator
The _blockTimedLoginUntilIdle method sets a timeout to be called after
the user is idle for 5 seconds. That timeout is erroneously given the
source name "[gnome-shell] this._timedLoginAnimationTime" which looks
like a copy-and-paste mistake. The original intention was probably to
use a source name of "[gnome-shell] this._timedLoginIdleTimeOutId" which
more closely matches existing convention for source names.
This commit fixes that.
Make sure the focus isn't grabbed right after user interaction starts a
new timed login. Only grab it after the idle timeout is done and on the
first run instead.
Normally, we give the user a 5 second grace period of inactivity before
starting a timed login operation. Unfortunately, that grace period
timeout isn't properly removed if the timed login operation is restarted
during the grace period. That means the timeout handler can
inadvertently get called multiple times leading to the grace period
duration getting subtracted from the total animation time more than
once.
This commit ensures we only ever have one grace period timeout scheduled
at a time.
The timed login feature currently cancels the timed login operation when
a user presses a key but, oddly, only hides the indicator when the user
releases the key. This means that if a user holds down a key that
doesn't key repeat, the timed login indicator will continue to run after
the timed login operation is cancelled.
This commit address the problem by ensuring the timed login indicator is
hidden on any key press event, at the same time the timed login
operation is canceled.
Call _st_set_text_from_style() when updating the entry's style, so
that CSS style properties such as text-decoration or letter-spacing
are applied over the internal ClutterText instance.
Modes, extensions and other GNOME Shell assets are searched in appropriate
subdirectories of each directory in XDG_DATA_DIRS, falling back
to global.datadir.
However, this isn't the case for themes, which are currently always expected
in global.datadir, even when referenced by a mode in a different XDG_DATA_DIR.
The fix is to have the theme finding pattern follow the same logic as other
elements.
Fixes#167.
The HIG discourages the use of icons in menus except for "noun" items
(files, bookmarks, ...). While those should be rarely used in the
application menu, it still makes sense to support them in the few
cases where they are used.
https://bugzilla.gnome.org/show_bug.cgi?id=760985
Otherwise it happens that porthole is computed again after that the
overlay is hidden (triggered by a layout reallocation) and thus not
regenerated again afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=792687
The author of the original URL-matching regex warns[0] that the pattern may
cause certain regex engines to lock up with certain input, namely patterns
that contain parentheses. It turns out SpiderMonkey is affected, but rather
than switching to the author's improved version (that is still crazy), sim-
plify the pattern a bit by removing support for nested parentheses in URLs.
Even a single pair of parentheses is extremely rare, so this is unlikely to
make a noticeable difference (other than not locking up SpiderMonkey of
course) ...
[0] http://daringfireball.net/2010/07/improved_regex_for_matching_urls
