While we don't actually require a more recent version at build time,
we do need the latest stable version at runtime. There's no strong
reason for making that differentiation, so bump the requirement.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1006
instead of explicit screen arguments and `gdk_screen_get_number()`, as nowadays there
is always only one screen. This silences some deprecation warnings and removes
deprecated API.
Bonus: some code style cleanups
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/422
Running dnf to update and install additional packages every time
the job is executed slows down the CI pipeline. Avoid this by
using another custom images for JS source checks.
In addition to the js shell we use for the existing syntax check,
also include eslint for future jobs and some extension-specific
tooling to make the image more useful to extension authors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
So far we are only performing a basic syntax check on javascript
sources; it's time to test the C code as well. As mutter is tightly
coupled, we bite the bullet and build it as well, either using a
matching branch (if it exists), or current master.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
Ouch, this went unnoticed for a long time: As the minimum size of menu
items is generally small (because its label can be ellipsized), we are
requesting the unellipsized width of the last "size child" instead of
the widest one.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/996
This adds a pipeline stage for merge requests that checks that the
commit message contains an URL to either a issue or a merge request.
This means that for merge requests without corresponding issues will
always fail initially, as the merge request URL is not known until after
it is created. This is still arguably better than accidentally merging
merge requests without URLs.
Taken from https://gitlab.gnome.org/GNOME/mutter/merge_requests/440.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/410
Here's a template string with '/' that escaped commit 94423151b2,
resulting in an xgettext warning when generating the .pot file.
Simply move it into the resource like the other interface descriptions
to make xgettext happy again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/407
Since commit deec0bf255, the texture cache is based on ClutterImage
rather than ClutterTexture. As ClutterImage (like all ClutterContent)
is only concerned with painting, it doesn't influence the size of the
actor it is added to at all, and the returned actor will now stay at
size 0x0 after the image has been loaded.
Set up the actor to follow the content's size instead, to get closer
to the previous behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/402
The top drag gesture is not of any use if the topmost window is not
a fullscreen window and will only block events near the important top
screen edge (i.e. the panel). To fix this, only enable this gesture if
the focus window is a fullscreen window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/552
If the user's real name is too long to fit the menu comfortably, we are
supposed to use the username instead. However since commit f8e5e3e435,
we no longer set a max-width on the menu as a whole, but instead base
the width request on only "unellipsizable" children. For some reason
the system menu ended up there, so the name is now allowed to grow
indefinitely.
Remove it from the list of size children to get the intended behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/400
The menu grabs the key focus when opened, which takes focus away from
whichever actor triggered the keyboard. And as the menu doesn't have
any text entries, the keyboard is popped down as a result.
Prevent this by making the menu items unfocusable, so the keyboard
focus just stays where it is. Considering that the menu is part
of the on-screen keyboard itself, not being keyboard-navigatable
isn't a big deal here.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
Menu items use a single 'active' state that follows both hover and
keyboard focus. It therefore makes sense for the active item to always
grab the focus, in particular as an item that is sensitive but not
focusable by keynav would be rather weird.
As it turns out, we do have a case that is weird enough where we want
exactly that, so only grab focus if the actor's :can-focus property
allows it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
