When using fractional scaling, the size of the loaded image with
applied scaling may still differ from the displayed size. This
is currently addressed by syncing the size of all slice actors
in the (probably only) caller.
Instead, set the actors to fill their parent automatically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2798>
The tests rely on the ability to run Clutter as stand-alone app,
which hasn't been possible for quite a while now. Event handling
was broken long before that, plus tests that need a human to run
them and evaluate the result aren't that useful to begin with.
It would be neat to test our CSS rendering by setting up a stage,
capturing it and comparing it to a reference image. But writing
some code that exercises backgrounds, borders etc. is hardly the
obstacle to make that happen, and not worth carrying around dead
code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2811>
This was necessary after mutter configured a non-root user
for the image, although as it turned out not sufficient.
The latest image no longer sets up a special user, so building
the toolbox image should work again as before.
This reverts commit ee384d85da.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2813>
The keybinding is a direct, less commonly used alternative to
stand-alone 'super'. While it can be useful to have a regular
keybinding alternative - although 'super+alt+up' also provides
that to some extent - most users probably don't even know about
it's existence.
It is therefore less justified to take away a valuable shortcut
slot, so stop assigning a default shortcut to free 'super+s' for
other actions.
Users who do use the keybinding can still use Settings to assign
a shortcut.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5670
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2716>
If gjs itself defines ARGV, it only holds the arguments that are
passed on to the script, and javascript code should combine the
programName and ARGV (or the newer programArgs) when it needs a
C-style argv array.
Do the same in the portal-helper process instead of passing along
the original C argv, to avoid confusion when accessing the arguments
from javascript.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2786>
We want to replace gjs' custom (and now legacy) imports system
with standard EcmaScript modules: JS developers are already
familiar with them, they have better tooling support and using
standard features over non-standard ones is generally the right
thing to do.
Our D-Bus services are separate from the main process, and thus
can be ported separately (except for the few imports that are
shared with the main process' code base).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2786>
- spin out all the panel button styling into a drawing mixin
- clean up the styles generally
- make special cases for the clock and non-flat buttons
- contrast fixes for non-flat buttons, fixes#6768
- new stop icon for the screen recording/cast indicators
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2804>
GTK 4.12 deprecates gdk_wayland_toplevel_unexport_handle() in favor
of the new gdk_wayland_toplevel_drop_exported_handle(). We are not
bound by API stability, so we can just expose the additional argument
that the replacement requires instead of tracking the handle
internally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2778>
We currently special-case the DISABLED error when initializing
filtering, but not on app filter changes.
While it seems reasonable that Malcontent.Manager wouldn't emit
the signal while disabled, that's not actually true: It is emitted
when any user account information tracked by AccountsServices
changes.
Even if the signal were limited to changes of the ParentalControls
extension, it would still get emitted when app filtering *becomes*
disabled.
So regardless of potential improvements in libmalcontent itself,
we should filter out the DISABLED consistently, both when creating
the initial filter and when updating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2796>
Commit c449058d44 changed the pointer clone to use a single
actor. However that broke applying the hotspot translation to the
position, so the magnified cursor is now displayed with a shift.
Undo the change to restore the old behavior.
This reverts commit c449058d44.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2780>
gjs now has an internal mainloop that it can spin to resolve
module imports. That loop uses the thread default context,
so its possible that other sources, namely from mutter, get
dispatched when iterating the context. If that happens before
mutter is properly initialized, this will lead to a crash.
GjsContext needs to iterate its internal mainloop when initializing
to resolve internal modules, to avoid iterating Meta's mainloop and
triggering events before Meta is ready we will initialize the Shell
global and thus the GjsContext (js_context) before Meta.
Once GjsContext is initialized, we can call meta_context_setup().
Once Meta is setup and started, we'll run init.js which uses GJS'
internal promises API to set a "mainloop hook". The mainloop hook
is run immediately after the module returns so GJS will not attempt
to iterate the main loop again before exiting.
Also adjust the 'headlessStart' test to not wait for the
MetaContext::started signal, as that signal has now already
been emitted when the code is executed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6691
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2781>
get_size() in _syncAnimationSize() can't be called until the actor
has a parent, otherwise we'll get an error for calling
st_get_theme_node() prior to the actor being on a stage.
_syncAnimationSize() is called asynchronously via
textureCache.load_sliced_image() and there is currently no guarantee
the actor will actually be "loaded" prior to calling it.
This becomes a more obvious error/issue when refactoring parts of the
Shell loading to also be asynchronous.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2563>
The windows we create use a simple pattern as content, as that's
easier to follow than completely empty windows. GTK4 no longer
allows hooking into the drawing of arbitrary widgets, so prepare
for that by using a dedicated subclass instead of a signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
We are about to port the helper proxy to GApplication, which means
that it will establish a display connection before exporting its
D-Bus name. That means that the compositor must be able to respond
to a roundtrip request to avoid locking, so don't block on the proxy
becoming available.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
There's another remaining bit of Gtk3 code in a small test program
that changes a window title to a random character sequence every
five seconds. While the value of that test is a bit questionable,
it doesn't hurt either and a port is trivial.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
Its only purpose is to provide a test case for the remote app menu,
but that support was removed in gnome-shell years ago. We don't
need a test case for GTK's fallback app menu support, so remove
the whole thing.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
Now that we track apps instead of instances, we can make the menu
items activatable, because the corresponding action is no longer
app specific (like activating a particular tab): We can simply
activate the app, which hopefully will bring it to the foreground
again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
The background apps menu currently tracks instances rather than
apps. That matches the behavior of `flatpak ps` and can be useful,
for example when one particular instance runs out of control.
But as we don't include any information that allows to actually
distinguish between instances, multiple instances appear simply
as duplicated app entries.
Given that a menu is too limited for detailed information, stop
representing individual instances, and track apps instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
