This keymap requires the corresponding input method for Hangul
input, and the hangul mode to be enabled. Look up for the right
state, and use a corresponding 'us' keymap for english input
otherwise, in order to follow hangul IM behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Add latched keys a distinct color again (mainly for alt/ctrl being
notoriously active), and tweak the suggestions box sizes so there are
no size jumps between an empty and a populated suggestions box.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Make these closer to the mockups, on most locales at least.
Unclear/remaining are:
am, ara, il, in+mal, ir, kg, mk, mn, rs, ru, th, ua
Since the extended OSK keymap is short on space, it coalesced
both keys together (i.e. extending the extra keys popup) so it
takes less room.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Have these defined in the JSON files themselves, instead of trying
to add them from JS while minding the differences in number of levels
and rows.
This means more redundant data in the JSON files, but simplifies
OSK layout creation significantly, and allows finer control over the
appearance without quirks.
As a result, importing data from CLDR is no longer as straightforward
as running an script. After initial import, manual editions will be
required to add missing keys, assign key widths, and so on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
We want to extend the data model with additional keys, actions,
and properties. We need keys to be a map instead of a plain array
of strings.
Adapt the script to dump data in this new format, so it generates
a decent base to manually complete the work.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
As per feedback, remove the visible styling of the page indicators.
They're still used to layout and detect drag hovering, so the actors
are still in place, but they're completely transparent now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Make the next and previous page arrows be StButtons, with their
'icon-name' property matching the current StIcon icon name, and
use the 'clicked' signal to switch pages.
Remove the 'button-press' callback the scroll view, since the
buttons take over this functionality.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Now that wi-fi devices will be handled by a separate menu toggle
instead of as part of a combined system menu, there is no longer
a need of delegating network selection to a separate dialog.
To keep the menu from growing too much, the (sorted) list of
displayed networks is kept at a limit of eight. There is always
Settings for a complete list…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
There's no visible change here since we're just moving from the
default transparent black to transparent other. But the latter can
be used as a special value to indicate to the rendering code when a
background is expected to be always occluded.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1915>
Now that the old system menu has been ported over, we can move
the power toggle to its intended place. The main difference to
the stand-alone toggle is that the button now uses its natural
size rather than the fixed size of regular quick items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
This port is a bit messier than the previous ones, because the
existing menu section translates less directly to the new UI,
which uses a row of individual toggles for settings, lock and
shutdown.
In order to not complicate the grid layout further by supporting
rows with a different number of columns than the overall grid and
children at their natural size, create a custom, non-reactive
SystemItem item that spans an entire row, and contains the individual
toggles.
This works quite well, even with the shutdown item that uses a menu
for the various actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
Now that the QuickSettingsMenu supports child menus, it is time
to add menu support to quick toggles.
Do that by introducing a QuickSettingsItem parent class with a
construct-only :has-menu property, as that will allow including
menus in items that aren't following the standard icon+label
pattern of QuickToggle (yes, we'll have some of those).
A common parent class also allows us to control the type of
menu that is created. That's important, as we need another
custom menu type to
- constrain the menu's y position to place it underneath
the source actor
- use open/close animations taylored for this use case
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
The aggregate menu with its submenus isn't well-suited for simple
on-off actions, so we didn't expose the global color-scheme support
that was introduced last cycle.
Quick settings on the other hand are a natural fit for actions like
this, so add a corresponding toggle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The quick settings menu is a popover that arranges items in a
reflowing, homogeneous grid. Grid children may span multiple
columns, but not rows.
For now the QuickSettingsMenu that contains the grid is just a
convenience wrapper around the layout manager that does the heavy
lifting. The two will become more intertwined when we add support
for menu toggles though, so the custom menu type is unfortunately
needed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The latest mockups move the screen sharing indicator into a
separate control, similar to the existing indicator for built-in
screen recordings.
As this removes the submenu and only keeps the top bar icon (for
external screen recordings), this will smooth the transition to
quick settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
`ShouldShowAirplaneMode` only considers whether airplane mode
should be shown for the form factor, not whether there are
any actual kill switches available.
That's tracked in a separate property, `HasAirplaneMode`.
Take that into account for our `:show-airplane-mode` property,
so that it reflects when airplane mode should and *can* be shown.
Right now we only show airplane mode when it is enabled (and
therefore available), but this will change in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
