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).
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.
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
Since commit 78a92fb6be we no longer pop up authentication dialogs
on the lock screen, however any dialog that is already open at that
time remains open. This is unexpected, so hide the dialog until
the screen is unlocked again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/166
Since commit 1939e22c22, we move the keyboard focus with the hover
highlight. However while this makes sense when interacting with
the window picker, it interferes with keyboard navigation of other
components like dash or top bar. Address this by only moving the
focus when the previous focus was already inside the window picker
or unset.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/50
The original UTC support in GWeather piggy-backed on the existing API, but
as "country" or "city" don't make sense in the context of UTC or AoE, the
concept of "named timezones" was introduced. Handle those explicitly to get
back labels for those locations.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/150
We don't toggle the overview if the request happens too close to the
last activation, to filter out double-clicks or activation by both
the hot corner and a click. However as the check is based on the
real time, the check breaks if the system clock moves backwards and
the last activations appears to be in the future. Fix this by using
monotonic time which is guaranteed to only move forward.
https://bugzilla.gnome.org/show_bug.cgi?id=763886
While polkit requests *should* be the result of a user action, that's
not always the case in practice and authentication dialogs can pop up
out of nowhere at any time. That's always annoying, but particularly
bad on the lock screen. If we disabled the polkit component altogether,
the fallback GTK-based agent would kick in, so instead handle the case
explicitly and postpone showing the dialog until the session is unlocked.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/179
Even though we are using an "xkb" source, it still makes sense to
pass the event through the IBus simple engine, in order to let it
handle compose keys and ctrl+shift+[u|e].
https://gitlab.gnome.org/GNOME/gnome-shell/issues/115Closes: #115
boltd 0.2 gained a property that indicates if it is authorizing
devices or not. If it indeed is not authorizing then we wont
try to enroll new devices because that would otherwise lead to
and error.
When we move keyboard focus to the search entry, we replay the key press
that triggered the move to the entry using ClutterActor's event() method.
Since commit 3b293e91e we specify that the event is in the capture phase
to make it work with StIMText, but now that commit 83accce24 removed it,
we have to return to the expected non-capture flag that matches the orig-
inal event to unbreak find-as-you-type functionality.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/72
Find-as-you type was never automatically handled by StIMText, but
by the existing stage key-press handler. The functionality broke
for a different reason, we will fix it after reverting the recent
captured-event changes.
This reverts commits bc4462cd0c and e4ee944d8d.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/72
Since commit c4f2bb5f, close buttons are hidden by making them fully
transparent rather than setting their visibility to false to keep
the overall message layout stable. As a result, the buttons now work
even when invisible, which is clearly unexpected - fix this by updating
the reactive property appropriately.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/66
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
imports.misc.ibusManager.IBus is declared as const, so referencing it
from another module triggers a warning with recent mozjs. As of commit
083d11a032 IBus is mandatory, so just make it a regular import to avoid
the warning.
Right now we emit session-activated any time the bullet
moves in the session menu. That includes at startup when
picking an item arbitrarily, and any time GDM reports the
session was read from the user's account settings.
session-activated informs GDM about the newly selected session,
so emitting it in response to GDM reporting a session is a
bad idea.
This commit changes the code to only emit session-activated when
the user explicitly activates a session item from the gear menu.
Note, we no longer set the active session explicitly at start up.
This is a good thing since the item we were picking wasn't
necessarily correct. It does means if GDM fails to inform us
about the correct default session we'll now show no bullet instead
of a bullet on the wrong item.
https://bugzilla.gnome.org/show_bug.cgi?id=740142
gnome-shell currently initiates an automatic login attempt if
timed login is enabled and the timed login animation completes.
Unfortunately, if animations are disabled (as is the case for
virtual machines) then the timed login animation will complete
instantly, and timed login will proceed immediately after gnome-shell
has noticed the user is idle for 5 seconds.
This commit addresses that problem by initiating timed login and the
animation from a main loop timeout, instead of using the tweener api.
This is pseudo-class is added on .shift-key-uppercase whenever the shift
state is latched, a matching selector would be:
.keyboard-key.shift-key-uppercase:latched {}
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Drop the UTF8 glyphs from those, and add style classes so those can be
specifically themed and given a background image. The style classes are:
.keyboard-key.enter-key{}
.keyboard-key.shift-key-lowercase{} /* applies while lowercase */
.keyboard-key.shift-key-uppercase{} /* applies while uppercase */
.keyboard-key.layout-key{}
.keyboard-key.hide-key{}
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Do the finicky checks to adjust key widths and whatnot based on other
values than the label. This makes the label exclusively used for
presentation (i.e. setting up a St.Label).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Instead of latching all states, make shift unlatched by default, and only
latched when making a long press on the key. When not latched, the keyboard
will switch to the first level (alphabetic lowercase) after the first key
press.
Also, move the actual level switch to Key::pressed, so it feels more
reactive on long press.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
