We shouldn't allow toggling menus that aren't supported by the
current session mode, but as indicators are hidden rather than
destroyed on mode switches, it is not enough to check for an
indicator's existence.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/851
This keyboard works similar to GTK+'s emoji chooser (actually, both pull
from the same JSON file). Emojis are categorized in sections and variants
and kept in a "model".
The EmojiPager actor then uses this model to generate pages on-the-fly as
the user swipes around. This is an important optimization since the amount
of actors would rival with the rest of the shell otherwise.
The EmojiSelection object puts the EmojiPager, the page indicators and
a KeyContainer with the bottom row of emoji section shortcuts together to
implement the emoji panel as a whole.
The Keyboard object hooked this to an "emoji" key, which is just visible
on the Clutter.InputContentPurpose where showing an emoji would be
meaningful. Otherwise the surrounding buttons are made a bit wider to
cover up for it (i.e. as it was before).
In order to cater for emoji panel usage, we want something like PageIndicators
except:
- It should have horizontal disposition
- It should not be animatable (?)
- It should not be reactive
Separated PageIndicators into a base, non-animated widget, and an
AnimatedPageIndicators that can be used on appDisplay.js. Reactiveness is
set through an extra method, and layout is set as a construct argument.
This will be useful as we want other panels (eg. emoji) to preserve aspect
ratio with the rest of the OSK. Separate the aspect ratio management logic
into this container that will be the parent of them all.
Since commit 447bf55e45 we turn the top bar translucent when
free-floating. While this looks fancy and reduces the appearance
of cutting into the available screen space, it has also had a
negative effect on legibility.
Nobody stepped up to address those issues in two years, so revert
back to the fully opaque top bar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/408
While the current textual forecast is non-intrusive, it may be too
much so, making it less effective to spot the current conditions
at a glance.
Refresh the section to use a more conventional graphical representation,
similar to the one used by gnome-weather itself.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
Having Unity-like shortcuts for activating the first nine applications
in the dash has been a long requested feature, but somehow nobody got
around to implement it.
As the shortcut is most useful outside the overview where the dash is
not visible, only consider favorite apps as they have a predictable
order.
https://bugzilla.gnome.org/show_bug.cgi?id=648000
Since the overlays we show on hover above the window clones are no
longer only a close button, but the window title, a border and a close
button, rename a few variables so it's easier to understand what they're
for.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/346
Currently when a preference widget fails to load, we throw a raw
backtrace at the user. While that is undoubtedly useful information
for extension developers and bug reports, it is gibberish to most
users and hardly the first thing they should be exposed to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/193
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
In order to replace GTK+'s GtkPolicyType. It's bit-compatible with it, too.
All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
This is actually papering over bugs in toolkits. On X11 the Xserver will
send crossing events when the stage input shape changes. As those go
end up ignored in GTK+, this warp call aims (and randomly manages) to send
a motion event that wouldn't go unlistened by the drag source window (the
one holding the grab).
This bug actually manifests in other ways, eg. by changing the window
beneath the pointer with alt-tab while DnDing. This should be fixed
altogether in the client side.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
This gdk_display_sync() call was added in commit a40daa3c22 so the alt-f2
dialog is able to spawn commands that trigger grabs on startup (eg. xmag/
xkill).
This seems worthwhile to do only on the X11 backend, and handling it in
mutter backend code seems cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
Allow notifications to set a x-gnome-privacy-scope hint, with values in
['system', 'user']. If all the notifications in a particular source hint
that their privacy scope is ‘system’, don’t hide the notification
details on the lock screen.
This is aimed at fixing the particular case of power notifications: they
contain information which is not private to the user (it relates to the
system: battery state or AC state, which is obvious to anyone who can
see the machine), so hiding the details of a power management
notification when the screen is locked is pointless.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/issues/726
Most often it is a bug if the condition part of a for-loop contains the
assignment operator rather than the comparison one, so tools rightfully
emit a warning.
Clarify that the assignment is intentional in this case by adding
parentheses.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/375
