Menu toggles are currently regular toggles with an additional
arrow button. This allows for a simpler implementation, but
has downsides with regards to keyboard navigation and hover
feedback.
To make it more obvious that the two parts of the menu toggle
perform different actions, change the overall structure of the
toggle to *contain* a regular toggle and the menu button.
That way each element uses its own hover effect, and shows up
in the keynav focus chain.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5964
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2632>
GTK4 changed icon loading significantly, it is now closely tied
to snapshots and paintables. This makes a port highly unrealistic,
so to avoid staying stuck on GTK3 forever, copy the relevant code
into the tree.
The code is unmodified except for the include names and replacing
some stray tab indentation. It is still full of GTK internals, so
it will take a while before we can actually build it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
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>
These two are moving into gnome-shell to unify screenshot handling and
allow for same-frame capturing.
While we're at it, move the keybindings .xml file from g-c-c here
because it belongs to gnome-shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
There is a big overlap between the app menu in the top bar and the
context menu of app icons. It makes sense to unify the two both
from a design- and from a code perspective, so split out the more
modern one into a separate module as basis for a shared class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
When we allow users to choose between different templates, we should
provide some context for each template to facilitate that choice.
Add that metadata in the form of a .desktop file, which allows us to
specify name and description, and is well supported by our translation
infrastructure.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
The Extensions app code is now independent enough from the rest of the code
base to move it to its own subprojects, like we did for the extensions-tool.
This allows for stand-alone builds of the app, which we are about to use
for distributing it as flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
As outlined earlier, in order to turn the Extensions app into a properly
sandboxed application, we need to split out the extension prefs dialog
and move it elsewhere.
With "elsewhere" being the new Extensions D-Bus service, effectively
turning it into a shell extensions portal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
The dialog that contains the extension's preference widget has become
fairly complex over time, mostly due to the error handling.
It therefore makes sense to move it to a template, just like we did
for the main application window and extension rows.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
The gnome-extensions tool code is really independent from the rest of the
code base, and could be used either as part of the gnome-shell build or as
stand-alone project (for example for the extension-ci docker image).
We can actually support both cases by moving the code to a subproject.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
Adds the UI part for the pointer accessibility features.
The various timeouts running are notified using a pie-timer showing
under the pointer.
For dwell-click type selection, we use a drop-down menu. Users can
use the dwell-click to select the next type of dwell click to be
emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/474
Show a dialog informing the user each time the keyboard accessibility
flags are changed by one of the clutter backends (either from toggle
keys or two-keys-off modifiers).
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Every action has specific associated terms that
identify that action and show it in the search
results. Methods to match the actions as well
as getting properties of specific actions are
needed in order to provide a way of using the
actions.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
When using the meson build system, gvc will be built as a subproject.
As meson restricts submodules to a subprojects/ directory in the
source tree root, move the submodule there.
https://bugzilla.gnome.org/show_bug.cgi?id=783229
This is an implementation of the pad OSD that's been previously
present in gnome-settings-daemon. Since things are moving closer
to the compositor, it makes sense to have this implemented as shell
UI.
https://bugzilla.gnome.org/show_bug.cgi?id=771067
intltool is unmaintained nowadays while upstream gettext gained
support for formats like GSettings schemas and .desktop files,
and offers a mechanism to teach it about other XML formats not
yet supported out of the box which we can use for the rest.
So there's nothing stopping us, just make the switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=769074
We lost media controls outside of notification banners when
implementing the new notification designs. Reimplement this
functionality as a dedicated "Media" section in the message
list based on MPRIS.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
Currently both the base classes for messages/sections and the message
list itself that instantiates the available sections are located in
the same module. As a result, it isn't possible to define sections
in a different module without introducing circular dependencies. The
Calendar module is already unwieldily large, so split it up a bit to
avoid it growing even bigger in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
While legacy status icons are notoriously bad with regard to
accessibility (well, among many other things), we should still
make them available via ctrl-alt-tab ...
https://bugzilla.gnome.org/show_bug.cgi?id=746022
search.js used to do a lot more, but now that most of the
functionality has been moved to the remote search system,
it doesn't do a lot. Merge searchDisplay.js into it.
