Pretty much the same case of the previous commit: we want this size
to be scale-dependant, and using the width and height properties of
ClutterActor doesn't automatically update.
Use CSS to set the width and height.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
Each node stores the scale factor in place when it was created.
Creating nodes with the same style, but with different scale
factors, yields different nodes.
Use the node's scale factor instead of retrieving the context's
one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
Just like StIcon does, we should use a container widget for the fallback
app icon that we get using the cairo surface property. It's needed
because the widget returned by shell_app_create_icon_texture() can be
resized freely, while we want the aspect ratio of the actual texture to
remain the same.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2578
(cherry picked from commit 85846d88f0)
Since commit 6a42d77261 we invalidate the
cached properties for each theme node on stylesheet changes by iterating
over the hashtable of the theme context instead of listening to the
signal in each individual theme node.
That commit forgot one particular node though that's not stored in the
hashtable, but using the `priv->root_node` property instead: The theme
node that belongs to the stage.
So make sure we also invalidate the cached properties of the stage theme
node on stylesheet changes. This fixes various crashes that happened
with extensions providing custom stylesheets (emitting the
"custom-stylesheets-changed" signal on every extension enable/disable),
trying to access an already freed CSS property of the stage.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2584
(cherry picked from commit bc973b80d7)
Now that the extension preference dialog is opened by a separate
D-Bus service rather than the Extensions app, it can be opened
without a parent window that provides name and icon.
Fix this by adding back a hidden .desktop file.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2562
(cherry picked from commit 6b7c85b079)
Predefined categories aren't a great way for organizing installed
applications, but they have their use in "stores" like Software
or flathub.
Not listing any category means we fall through the cracks, so
pick the (hopefully) least inappropriate one ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1160
(cherry picked from commit 360f5b1642)
Commit 7ff7fb5d3b forgot to clear the
`priv->icon_texture` actor when returning from st_icon_update(), which
means we don't always switch to an empty icon if both gicon properties
are set to NULL.
Fix this and destroy the actor before returning early from
st_icon_update().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1178
(cherry picked from commit 07deda593a)
Usually the screen is woken up before the shield is deactivated, but
it is also possible to unlock the session programmatically via the
org.gnome.ScreenSaver D-Bus API.
The intention is very likely not to unlock a turned off screen in
that case. Nor does it seem like a good idea to change the lock
state without any indication.
Waking up the screen is more likely to meet expectations and is
more reasonable too, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1158
(cherry picked from commit fbe2e30f38)
Commit c89d6a633 introduced a default fallback icon that would be displayed in
case the main gicon or the fallback gicon wasn't set or failed to load.
This broke the use case where a StIcon is created but no main icon or
fallback icon are set on purpose, for example the appindicator extension
which always creates a StIcon to represent icons in menu items but the
actual icons are only set if the application provides one, leaving the
menu showing the default fallback ("image-missing") icon for all menu
entries that don't actually have an icon provided by the application.
Fix that by only using the default fallback icon if the provided one
failed to load.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1173
(cherry picked from commit 7ff7fb5d3b)
Extension that want to expose their own preferences (for example as menu
items) do that by passing their UUID to gnome-shell-extension-prefs.
But since 3.36.1 the app is optional and no longer accepts arguments on
the command line. To adjust, extensions now need to make a D-Bus call
the extensions portal, just like the app and gnome-shell.
We will add a convenience method for that purpose, so it makes
sense to share the existing code. As it's extension-related, the
extension manager looks like the right place ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1163
(cherry picked from commit 45bc850715)
A promisified method expects the callback parameter to be either
a function (in which case the original method is called normally)
or omitted altogether (in which case a Promise is returned).
The call to open application details in Software does neither and
passes null instead, which will result in a warning (because no
function argument means a promise will be used, but not omitting
the parameter means we end up with too many arguments).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2551
Commit 83c6b2ab promisified the method in endSessionDialog, which means
that after the module is imported, every caller will get the promisifed
version. That can be a bit surprising in completely unrelated modules,
so commit 764527c8 (on master) moved the promisification of more common
methods into environment, as that's initialized early and expected to be
shared between anything else.
Do the same for the call() method on the stable branch.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2551
The app-cache code currently stores the folder translations in a hash
that can be accessed via shell_util_get_translated_folder_name().
This hash uses the filename (inc. extension) for the "desktop-directory"
as key which causes an issue when trying to find the translation
on AppDisplay._findBestFolderName() which gets categories (folder names)
from the app info which doesn't contain the ".directory" extension.
Fix that by storing the filename without extension as the hash key for
the cached folder translations.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1168
(cherry picked from commit 343b3351f1)
During the shell initialization we call the (deprecated) function to
override the Desktop environment in Gio DesktopAppInfo to make sure that
applications are correctly shown (as per commit b2fbf5a2), however this
might break the cases in which $XDG_CURRENT_DESKTOP is already set and
contains GNOME (given that is now a list).
In Ubuntu this is in fact set to: ubuntu:GNOME.
Now, if an application contains NotShowIn=ubuntu, the key will be ignored by
the shell, and the application is still listed everywhere.
So, override the DesktopAppInfo desktop environment only in the case that
the current desktop is not already GNOME.
At the current date I think we could just safely get rid of this override at
all, but there could be still cases where it still might be useful, like when
running as nested in some other environment, so keeping it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1156
(cherry picked from commit a0def23940)
In some situations we could end up not with lingering 'view-loaded'
handler. This could result in delayed spring animate-in being initiated,
e.g. after a minute after the activities overview was already closed.
Fix this by removing any lingering signal or later handlers when
unmapping.
Fixes: 5c33fe4a0ahttps://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1155
(cherry picked from commit f49b58cf97)
Starting the animation from the actor 'paint' signal has various
unwanted consequences, such as sometimes trigger a
clutter_actor_queue_relayout() during the paint phase. One unwanted
consequence was that an offscreen actor effect was disabled during
painting, meaning the effect would begin being active, but later during
the post-paint processing being disabled. The caused said effect to push
an offscreen framebuffer to the paint context, but then just destroy it
instead of popping it. When this happened, we'd end up trying to operate
on a framebuffer that may had been finalized, or not, depending on the
garbage collector. Sometimes, for some users, this caused a segmentation
fault when trying to pop a matrix from the framebuffer matrix stack.
Deal with this more properly, by using the 'view-loaded' signal to wait
with animation until the view is loaded, as well as using MetaLater to
schedule the start of the animation.
For when a view was signalled to be ready, we're in a state where we can
start animation before the next frame as the layout is ready, but when
not, we have to add back the "hack" where we must wait for one frame for
the target icon positions to be up to date. Do this by adding a
MetaLater IDLE callback that starts the animation *after* the next
frame. This also needs the old 'opacity = 0' work around to not show an
incorrect first frame.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2418https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1154
It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
Set the do not disturb label as the label actor for the do not disturb switch,
so that Orca speaks the do not disturb label when the user moves
keyboard focus to the do not disturb switch.
Also enable toggle mode for the "Do Not Disturb" button and bind it's checked
state to the state property of the switch. This makes sure that Orca presents
thecorrect state of the do not disturb switch to the user.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2508
It seems there is a weird race condition between Clutter trying to
destroy the keyboard actor and Clutter trying to hide the keyboardBox
container actor: If the keyboardBox is hidden before destroying the
keyboard actor, Clutter doesn't repaint anything and the keyboard
remains visible until something else draws over it.
To fix this issue until we find the underlying Clutter bug, simply
destroy the keyboard actor before hiding the keyboardBox. The order in
which we call these doesn't matter anyway since hideKeyboard(true) hides
the keyboard immediately without an animation.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1736https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
We're dealing with attached keyboards now using the touch_mode property
of ClutterSeat: If a device has a keyboard attached, the touch-mode is
FALSE and we won't automatically show the OSK on touches, also the
touch-mode gets set to FALSE when an external keyboard is being plugged
in, so that also hides the OSK automatically.
With that, we can now ignore keyboard devices when updating the last
used device and no longer have to special-case our own virtual devices.
Because there was no special-case for the virtual device we use on
Wayland now, this fixes a bug where the keyboard disappeared after
touching keys like Enter or Backspace.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2287https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
Since commit 2894085c45 we omit sound feedback on volume changes
if something is already outputting sound. Unfortunately that
"something" may be our own feedback (from a previous volume
change).
In that case we do not want to omit the new feedback, so instead
cancel the previous one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1147
This is documented as a value between 1 and 65536. However we were passing
a 0 value for 100% transparent colors, which is interpreted as "system
inherited" in pango_renderer_get_alpha() docs.
Ensure we respect this range by specifying the minimum allowed alpha (1)
if the color is fully transparent. If someone notices this 1/65535th change
I'll ask him how many pleiades can he count.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2504
(yes, again).
The offset argument is changing from uint to int. Which means we
might would pass a negative offset and trigger an "out of bounds"
error. Make it work more or less alright with older mutters, by
clamping the offset to 0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1146
Since commit 784c0b7e4 we use the name of the nearest city rather
than the weather station, as the latter tend to have unwieldy
and weird names.
However the nearest city may not be that near after all, in which
case the result is again surprising.
Address this by not using the nearest city name unconditionally, but
only if it appears in the station name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2468
AuthPrompt is created on demand, and this._authPrompt is
expected to be null except on very strictly controlled
occasions. The idle monitor callback isn't one of them.
Check if AuthPrompt exists before cancelling it.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2371
We finally have everything in place for distributing the Extensions app
as flatpak without jumping through too many hoops. Add a manifest that
can produce a nightly build like other GNOME modules, and can serve as
a template for a stable manifest on flathub.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
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
We include config.js because it is a dependency of ExtensionUtils,
but it's not actually used in the code paths we exercise.
As we want to allow stand-alone builds of the app, it is much easier to
fake the module than to either include a generated file from elsewhere
in the tree or generate it ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
Instead of adding a dragMonitor for every icon in the grid as soon as
one icon is getting dragged, only add a dragMonitor for the icon that is
currently being dragged over (ie. the current drag-target). With a large
number of icons in the iconGrid, this should significantly reduce lags
while dragging.
We can do this by detecting the DnD-entering of an icon or folder using
the `handleDragOver()` callback of drag-targets, adding the dragMonitor
because we know an icon is hovering above the drag-target and then
detecting the DnD-leaving of the drag-target by using the `dragMotion()`
handler, where we remove the dragMonitor again as soon as the
targetActor is no longer our actor (ie. the drag-target).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
While it should be impossible to destroy a FolderIcon while a DnD action
is still going on, there might still be rare cases where this happens
(ie. when a folder is removed because an app got deleted during DnD).
So make sure we're on the safe side here and don't potentially leave
dragMonitors around after the icon is destroyed by removing the
dragMonitor inside the onDestroy handler of the FolderIcon, just like we
do for AppIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
We want to completely clear the background framebuffer when switching
back to ACTOR mode to make sure the `background_fb.framebuffer` check
will fail in `update_background_fbo` when switching to BACKGROUND mode
again. Otherwise the checks in `update_background_fbo` will return TRUE
and we will keep using the background framebuffer that was created
before switchig to ACTOR mode.
While at it, also clear the background framebuffer completely when
changing the actor to avoid the same issue here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
When blurring only the actor (ACTOR mode), we don't want to apply any
scale, it looks fine without using the resource scale and it also seems
like `clutter_actor_continue_paint` in `paint_actor_offscreen` only
draws an unscaled texture anyway (ie. if the resource scale is 2, only a
quarter of the framebuffer is being drawn to).
In BACKGROUND mode though, we need to scale the framebuffer using the
scale factor of the stage view (ie. the final scale factor for the
monitor) because the content of the framebuffer we blit is scaled using
that factor. Also, since the framebuffer we blit belongs to a stage view
and only includes the contents of this view, we need to adjust the
stage-coordinates of the actor to be relative to the stage-view.
To make sure we don't have to get the transformed actor size or position
multiple times during one paint-run and don't have to carefully floor()
or ceil() widths and positions, store the size of the actor (which is
also the size of the framebuffer) and its position relative to the stage
view inside a ClutterActorBox.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
A ClutterEffect is being painted as part of the paint cycle of
ClutterActor, where _clutter_effect_paint() is called before painting
the actual actor. With that, it's impossible that an effect gets painted
while it's disabled, so remove the check whether the ClutterActorMeta is
enabled before painting.
Also if everything works fine in Clutter, the ClutterActorMeta should
have an actor set and we've been notified about that actor in
shell_blur_effect_set_actor(), so assert that our cached actor is set
when painting the effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
Forward the arguments at the 'delete-surrounding-text' signal
from IBusInputContext to clutter_input_method_delete_surrounding()
so that ibus-typing-booster use the deleting surrounding text function.
Input method engines can delete the output text in applications
with this function.
This change will require a change of mutter of mutter!517
because the first arguemnt of the 'delete-surrounding-text' is INT
to express the offset of the current cursor position but
the first one of clutter_input_method_delete_surrounding() is UINT
since the Wayland spec accepts UINT in delete_surrounding()
mutter will change the type of the first one to INT in
clutter_input_method_delete_surrounding() to work with this change.
https://gitlab.gnome.org/GNOME/mutter/issues/539https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/477
We had various requests to improve existing OSK layouts, but
haven't accepted them so far as any changes would be overridden
when regenerating the layouts.
However as the upstream layouts at http://www.unicode.org are
extremely slow to update(*), we shouldn't block all improvements.
So instead of letting the update script override all existing
layouts, just make it import new layouts.
(*) not their fault, as the android layouts are a downstream to Google
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1136
The module was imported into the toplevel in !424, but that's at
least a bit weird:
- it's a helper script for one particular aspect (OSK layouts)
- it adds a README.mdwn to our own README.md, and a test/ directory
to our tests/
Move the whole thing to a subdirectory under data/, which is more
appropriate.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1136
Use a brighter color and increase the contrast of the selected/active
items in the switcher popup.
Since a bright color doesn't go well with a box-shadow, remove that
shadow, an effect like should only be used for elements clicked with a
mouse anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1135
While we don't technically need the app to download and apply
updates, we do require it for notifying the user about available
updates and listing extensions with pending updates.
So instead of intransparently applying updates in the background
without the user noticing, disable updates altogether if the
Extensions app is not installed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2346
Blacklist support was added all the way back in commit 1e286e43, but
the code had been defunctional until recently. While uninstalling an
extension that has been blacklisted makes sense off-hand, unfortunately
we don't know if an extension was *actually* blacklisted:
The website returns that operation for any extensions for which it
doesn't find any versions that match the shell version. That is, the
most likely reason is that the user updated to a new GNOME release
which the extension doesn't support yet.
It doesn't look like the website is going to change that behavior any
time soon[0], so drop the 'blacklist' handling for the time being.
[0] https://gitlab.gnome.org/Infrastructure/extensions-web/-/issues/95https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1132
Commit 55b57421d changed signal handlers to the corresponding vfuncs,
but didn't always chain up as necessary. In most places this doesn't
matter, but at the very least the commit broke activating message list
items via the keyboard.
Add all (hopefully) the missing chain-ups to get the expected behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2319
Destroying the policy invalidates it, so accessing it from a
Source::destroy handler (for example to disconnect signal
handlers) currently results in warnings like:
Object .Gjs_ui_messageTray_NotificationApplicationPolicy
(0x7f8c7c0a64a0), has been already deallocated — impossible
to access it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2238
The idea behind commit 3dd8ffc2bb to try harder to avoid empty
icon actors because of missing icons was sound, so implement that
behavior in StIcon itself:
If the main gicon was not found, and the fallback gicon isn't set or
wasn't found either, fall back to the standard 'missing-image' icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
The commit broke StIcon's :fallback-gicon property, as it relies on failure to load
an icon to determine that the fallback should be shown.
Luckily StIcon is the only user of st_texture_cache_load_gicon() (at least in
regular shell code), so we'll be able to implement the 'image-missing' fallback
there.
This reverts commit 3dd8ffc2bb.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
In order to support OpenExtensionPrefs()'s parentWindow parameter,
we will need the ability to make a window transient to an external
window identified by a string handle.
This takes the corresponding code from xdg-desktop-portal-gtk and
brings it into an introspectable form, likewise the counterpart in
libportal to export a string handle for a GtkWindow.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1087
Since PackageKit 1.11.1, the prompt to install updates on the end
session dialog has been (mostly) broken. The problem is that it only
works if PackageKit is running at the time the end session dialog is
opened; otherwise, our GDBusProxy has invalidated all of its properties,
which we read to see if update is possible. We need to autostart
PackageKit before reading its properties to fix this problem. That would
be easy if we were calling a method to see if an update or distro
upgrade were available, but since we're just checking a property, using
cached properties won't suffice. We'll have to manually check the
property value to ensure we autostart PackageKit.
Most of the code is written by Florian. Thanks Florian!
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2276
Previously we'd show the system background and then wait till the
main loop was idle before beginning the shell startup animation.
This resulted in one initial frame that was always just the system
background.
Now we try to get both the system background and the startup animation
begun on the same first frame.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1102
In telepathyClient we consider messages both Tpl.TextEvents and
Tpl.Messages, and we manually create JS objects to copy the properties we
care for each one. This may lead to objects not matching the interface we
want.
Instead, use an object with construct-only properties and two factory static
methods to initialize it.
Unfortunately we need to use the ChatMessageClass for the class name or
calling the static methods would trigger a gjs error as per [1].
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1113
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/310
When mutter is acting as a display server it sets a number of
environment variables in the user's session. These variables
tell applications where the display server's sockets are.
When the shell exits at logout time it leaves these environment
variables in the systemd --user environment, which can confuse
subsequent sessions.
This commit clears up the environment on exit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1129
We now warn on startup if screen locking isn't available, however for
users who choose not to use GDM or logind, repeating the warning on
each login is more annoying than helpful.
Instead, limit the warning to the first login on which the screen lock
became unavailable. That way the notification will still serve the
intended purpose of informing the user, but without being perceived
as nagging.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
Add a small helper method to asynchronously "touch" a file and return
whether the file was created or not.
As g_file_make_directory_with_parents() doesn't have an async variant,
we need a C helper to make the entire operation non-blocking.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
It's easy to forget to add a new <release> tag to the metainfo when
doing a new release.
Address this with an additional test if appstream-util is recent
enough to include the new validate-version command, so distcheck
fails when the metainfo wasn't updated.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1117
Rely on the Pango renderer handling this properly, instead of tinting
the full ClutterText in the color specified through css.
Also set the caret color explicitly, since it used to be set as a side
effect of clutter_text_set_color(), but no longer is.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/850
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
If a given icon is not available for neither the current theme nor any
of the fallback options (default theme -"Adwaita", "gnome"...), the
call to gtk_icon_theme_lookup_by_gicon() will return a NULL value, which
returned by the Shell Toolkit as is, causing trouble in the Shell's JS
code when calling shell_app_create_icon_texture() to create an icon.
To at least mitigate the chances of this having this issue happening, we
should at least try to load the standad 'image-missing' icon from the
Icon Naming Specification spec when we receive a NULL here, so that
at least we try to show something to the user, even if it's ugly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1121
While sandboxing isn't a concern for the gnome-extensions command line
tool, using the Extensions proxy directly means that D-Bus methods are
called from the tool rather than gnome-shell, which allows the proxy
to auto-shutdown when done.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
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
Similar to the previously added org.freedesktop.Notifications proxy,
this exposes the org.gnome.Shell.Extensions API and forwards any
request to the real implementation in gnome-shell.
The motivation differs though: We want to be able to package the
extension app as flatpak and distribute it separately, but the
extension prefs dialog is hard to impossible to sandbox:
- filenames need translating between host and sandbox, and we
can only do that in some cases (serializing/deserializing
extensions), but not others (extension settings that refer
to files)
- system extensions install their GSettings schemas in the system
path; the best we can do there is assume a host prefix of /usr
and set GSETTINGS_SCHEMA_DIR in the flatpak (eeks)
- extensions may rely on additional typelibs that are present on
the host (for example because gnome-shell itself depends on
them), but not inside the sandbox - unless we bundle all of
gnome-shell's dependencies
- if gjs/mozjs differ between host and sandbox, extensions must
handle different runtimes for the extension and its prefs
And all those issues occur despite a very permissive sandbox (full
host filesystem access, full dconf access, full org.gnome.Shell
access (including Eval()!)).
This new service will give us an alternative place for handling
the preference dialog:
- it runs outside of gnome-shell process, so can open windows
- it runs on the host, so the extension's prefs get to run
in the same namespace as the extension itself
That is, the service will provide portal-like functionality (albeit
not using the org.freedesktop.portal.* namespace, as extension
management is an inherently privileged operation).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
We are jumping through quite some hoops to support showing only the
preference dialog when given a UUID on the command line.
As gnome-shell is about to stop calling out to us for the prefs dialog,
the reason for supporting this is going away, so remove all the special
handling.
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
On X11, _onFocusChanged() updates the input region, as well as the
reactive-ness of the dialog's buttons.
That method is not only used as signal handlers (which are correctly
disconnected when the dialog is hidden), it also runs when the "show"
transition completes.
That's a problem if the transition is still ongoing when the dialog is
hidden, as it will then only complete when it is replaced by the "hide"
transition, after the this._dialog has been reset to null, and trying
to access the dialog's buttons results in an error.
Avoid this by explicitly removing all transition on hide before
resetting the dialog.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2467
Commit c1ec7b2ff meant to fall back to the base layout in case
a variant like `fr+oss` is set up, but as we are checking for
'+' on the array rather than the layout name, the fallback only
"works" for a layout that is literally called '+', whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2471
Detailed notifications are meant to be single line, just as unexpanded
notification banners. So handle them the same way as in the message
list, and replace embedded newlines by spaces.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2463
We only show the list of system- and user extensions if corresponding
extensions are installed, however we only update the visibility
after loading the initial list of extensions.
As it's possible for the first user extension to be installed while the
app is open or the last one to be removed, we should also update the
list visibility after extension state changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1088
While we only shut down after a method call completed or (if the
interface has signals) the sender disconnects from the bus, services
may need to inhibit auto-shutdown for more specific reasons themselves,
for example when a method call kicks off an operation that should
complete before shutting down.
Add hold() and release() methods like Gio.Application for those cases.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1115
Whether we install bash-completion support currently depends on whether
the corresponding pkg-config dependency is found.
Turning this into a feature option keeps that behavior by default, but
also allows to explicitly enable or disable the support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1072
I always forget to keep the extension-tool version number in sync when
doing a new release. Given that it's unlikely that I'll do much better
in the future by myself, make distcheck fail when the versions don't
match.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1076
Some timezones, like the one of Kathmandu don't only have hour-based
timezone offsets, but their timezones are also offset by minutes. So
instead of showing weird values like "+5.8", show the minutes properly
in a format like "+5:45".
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2438
I misremembered that imports.package.start() would set up the correct
gettext domain, but the module only provides a convenience method
for doing that.
Use it to bring back translations in the Extensions app, whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1108
Now that the org.gnome.Shell.Extensions interface exposes the
disable-user-extensions setting on D-Bus, we can use that instead
of the shell's GSettings.
In a future where we distribute the app separately as flatpak, this
will require one less hole in the sandbox.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Using the "regular" loadInterfaceXML() helper means less code duplication,
but it also ties us to the resource used by gnome-shell.
In order to untangle the extension app from core gnome-shell, change that
to load the interface from the existing data resource instead. While that
does involve reimplementing loadInterfaceXML(), it's not too bad actually
with the resource-loading code stripped (as the data resource is already
loaded by the package module).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Extension updates are installed at startup, so any errors that bubble
up uncaught will prevent the startup to complete.
While the most likely error reason was addressed in the previous commit
(pending update for a no-longer exitent extension), it makes sense to
catch any kind of corrupt updates to not interfere with shell startup.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
When an extension is uninstalled, there is no point in keeping
a pending update: If the update didn't fail (which it currently
does), we would end up sneakily reinstalling the extension.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
Doing blocking IO in a graphical UI is bad, doing it in the compositor
is much much worse. So even if handling VPN requests is a relatively
rare event, doing it asynchronously is better.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
While we can use the libnm API directly from JS, the call will
synchronously load the VPN service descriptions from disk.
Previously we were lowering the impact by caching the result,
but as we stopped doing that, it becomes more important to address
the issue properly and move it off to a thread.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
libnm doesn't only search for plugins in the regular VPN plugin directory,
but also in the legacy location and the directory pointed to by the
NM_VPN_PLUGIN_DIR environment variable (if set).
We don't monitor the additional directories, so it's possible for our cache
to become outdated.
Instead of trying to play catch-up with libnm's internals, do what nm-applet
does and use the appropriate API to look up the plugin on each request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
checkForUpdates() will currently always query the server for updates,
even when passing an empty vardict of installed extensions. We know
there won't be any updates in that case, so avoid a pointless network
request.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1100
There are two ways for applications to provide a high contrast icon:
1. install an icon into the HighContrast theme
2. install a symbolic icon into the default hicolor theme
The latter is preferred nowadays, and implemented in the high-contrast
CSS variant by enforcing the symbolic icon style.
However together with the way we currently enable/disable high-contrast,
this can lead to the following race:
1. the GTK theme is changed from HighContrast
2. we reload the default stylesheet
3. the icon style changes to "regular", so we request a
new icon from the HighContrast icon theme
4. the icon theme is changed from HighContrast
5. we evict existing icons from the cache
6. we reload icons for the new icon theme; however as we
find a pending request (from 3), we re-use it
7. the request from 3 finishes, and we end up with a
wrong icon in the cache
The simplest fix is to change the icon theme before the GTK theme: Unlike the
theme name, the icon style is encoded in the cache key, so we won't re-use
an old (and incorrect) request in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2414
The SignalQuality property is defined on the GDBusProxy, not the modem
JS object.
Fix this runtime warning:
JS WARNING: [resource:///org/gnome/shell/misc/modemManager.js 252]: reference to undefined property "SignalQuality"
JS ERROR: TypeError: this.SignalQuality is undefined
_reloadSignalQuality@resource:///org/gnome/shell/misc/modemManager.js:252:34
_init@resource:///org/gnome/shell/misc/modemManager.js:234:14
NMDeviceModem@resource:///org/gnome/shell/ui/status/network.js:517:34
_deviceAdded@resource:///org/gnome/shell/ui/status/network.js:1755:27
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1097
When launching the default calendar application, we special-case
evolution to make sure it starts up with the calendar component.
This is currently broken in two ways:
- evolution changed its .desktop file to use reverse DNS notation
- as evolution can now be distributed via flatpak, we can no longer
assume that 'evolution-calendar.desktop' exists when evolution does
(even though we ship the .desktop file ourselves, it is considered
invalid if the executable isn't found)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1093
At least for the time being, this looks like the easiest option to
launch the service:
- we could add a systemd unit, but then we'd need to update the
RequiredComponents in the fallback session definition as well,
making it necessary for gnome-shell, gnome-shell-extensions and
gnome-session to be updated to 3.36.1 in lockstep
- autostart is problematic as it would make gnome-shell conflict
with other notification daemons; also autostart is most useful
with automatic shutdown, which would require tracking signal
subscriber to determine when the service is unused
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
Add a small service that exposes the Fdo notification API under the
well-known name, and forwards any requests to the actual implementation
in the shell.
That way any app with permission to talk to org.freedesktop.Notifications
will get exactly that, and nothing more.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
For sandboxed apps, permission to talk to org.freedesktop.Notifications
looks innocent enough. However as all exported services share the same
connection to the session bus, that permission actually grants an app
access to *any* shell D-Bus API.
While we want apps to use the notification portal, it is still common
for apps to use libnotify, raw D-Bus calls or even notify-send.
We don't want to give those apps a way to circumvent most of the sandbox
restrictions, so stop owning the org.freedesktop.Notifications name.
In a next step we will implement a separate notification-daemon that
exposes the API on the well-known address and proxies any requests to
the real implementation in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
There are a couple of D-Bus services that are currently provided by
gnome-shell for which it makes sense to move them fully or partially
into separate processes:
- screen recording (performance)
- FDO notifications (security)
- Extensions (portalization)
Add some base classes and build system glue to take care of the
common boilerplate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
Commit 88ac339774 changed StEntry behavior so the text hint would
stay visible while focused, as long as the text buffer is empty.
However, IMs that use preedit still should count as "started typing",
while the text buffer is still officially empty.
To fix this, check on st_entry_update_hint_visibility() that there's
indeed no preedit buffer before showing the hint. We can't directly
listen to internal preedit buffer changes in ClutterText, so handle
preedit buffer updates through the ::cursor-changed signal that will
be indirectly emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1084
These paths are meant for Xwayland, not for X11 compositors being restarted
through alt-f2 + r. Maybe some signal analogous to init-xserver should be
added for Xwayland shutdown paths, but this signal we are currently
listening for is backend agnostic.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2329
st_texture_cache_bind_weak_notify calls g_clear_signal_handler which
then calls st_texture_cache_free_bind. st_texture_cache_free_bind frees
the bind structure, so by the time g_clear_signal_handler tries to write
bind->notify_signal_id, bind has already been freed.
Fix this by using g_signal_handler_disconnect instead.
This partially reverts 135d178d08
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2334
Since the FolderViews are not connected to the "installed-changed"
signal, we need to reload their apps by calling _redisplay() when an app
is removed or installed. We can't connect to "installed-changed" inside
FolderView because we need to ensure _redisplay() of the FolderView is
called before AppView tries to access the apps of the folder inside
_refilterApps(). So reload the FolderViews inside AllViews _redisplay()
implementation to ensure everything is up to date before accessing the
apps of the folder.
Since the "apps-changed" signal of FolderIcon now indirectly triggers a
_redisplay() of the FolderViews, the 'changed' handler of FolderView is
now redundant and can be removed. Because of this, we also need to move
the emission of the "apps-changed" signal to the start of the signal
handler to make sure the view is updated before we try to access items
of the view.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1901https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
We should disconnect the folders "changed" signal from the folder in
case the FolderView or FolderIcon is destroyed. While at it, also remove
the unused this._spaceReadySignalId of FolderIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The _redisplay() function is usally used for subclasses of BaseAppView
which want to implement their own _redisplay() function, having that
function name in two classes which have nothing to do with BaseAppView
can be quite confusing. Make those names less confusing and call the
functions _sync() and _rebuildMenu() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The viewBox has a border applied, so when we call adaptToSize using only
the content box of the container, the width of the border is not removed
from the content box and the grid will be allocated less space than what
we told it before using adaptToSize.
Fix that by adjusting the content box for the size of the viewBox, too.
This makes sure the correct amount of columns can be shown inside a
folder, since right now we only show 3 colums even though 4 would fit.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
Some (newer?) GCC versions complain when a g_auto variable isn't
initialized when declared, even when the initialization is guaranteed
to happen before the variable is used or goes out of scope.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2298
Since 38da479ee we correctly ceil the non-integer radius of the slider
handle when calculating the offset for drawing the circle. Since the
handle also has a border with a width of 1px by default, we should also
factor that in when calculating the offset.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Along the lines of `styleSheetName`, a session mode may want to provide its
own gresource file, so make this possible via a `themeResourceName` session
mode parameter, defaulted to gnome-shell-theme.gresource
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1063
Unlike any other methods in the Extensions API, LaunchExtensionPrefs()
opens what appears to be an application dialog, except that it is
really a separate application that the caller has no control over.
In order to address that, add a new OpenExtensionPrefs() method that
takes additional parameters (modelled after the desktop portal APIs)
that will make it possible to improve the behavior in the future.
The new parameters are ignored for now, but pushing the API out now
will allow us to fill in the functionality post the .0 release.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
The 'disable-user-extensions' GSettings key is the last extensions-related
setting that isn't exposed over D-Bus, and therefore requires consumers
to access the GSettings directly.
Expose the setting as UserExtensionsEnabled readwrite property in the
org.gnome.Shell.Extensions interface to allow consumers to manage
extensions purely via D-Bus.
The 'disable-user-extensions' setting is the last extension-related
bit from the org.gnome.shell GSettings schema that is not exposed
via D-Bus.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
This (mistakenly) now only depends on signals triggered on Wayland
sessions. Hardcoding the XIM support on X11 sessions will make input
in some clients work again.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1690
Currently, a failure to start the Systemd unit `gsd-xsettings.target`
would be considered a failure to start Xwayland.
That means that if `gsd-xsettings.target` fails to start for whatever
reason, no X11 client can be used on Wayland.
However, XSettings is by no mean mandatory for X11 clients and many
legacy X11 clients do not implement XSettings. Those who do always have
a fallback path and therefore can still work without XSettings.
Make a failure to start the Systemd unit `gsd-xsettings.target` non
blocking for Xwayland, and just log a warning message.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1065
Now that Xwayland startup is asynchronous, the function may be called
before X11 is available, resulting in a crash.
Fix this by only managing the tray immediately if we already have an
X11 display, and wait for it to be set up otherwise.
Likewise, unmanage the screen when X11 becomes unavailable.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
Since support for legacy status icons is implemented by extensions
nowadays, they need to undo the call to manage_screen() when they
are disabled.
Right now that means bypassing garbage collection with an explicit
call to run_dispose() on the Shell.TrayManager. That works, but is
rather ugly.
An explicit unmanage_screen() method is a nicer option, and will be
useful to us as well to deal with X11 going away (once Xwayland
crashes don't bring down the entire session).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
NaTrayManager in particular is deeply tied to X11. We currently assume
that X11 support is always available, but that is already not true
anymore - Xwayland startup is now asynchronous.
It will be even less true once we handle Xwayland crashes gracefully.
Start addressing that by not creating the corresponding resources once
and assume they exist for the lifetime of Shell.TrayManager, but make
sure they exist when actually needed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
We ended up always showing the switch-user button on the lock screen,
as showing and hiding it with the prompt was too visually distracting.
But now that we have a fancy transition in place, we can easily extend
it to the switch-user button as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We only call _updateSensitivity() to make elements sensitive, and
nothing ever touches the sensitivity of the switch-user button; so
just call the corresponding authPrompt method directly, which is the
only bit that has an actual effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We do spawn gsd-xsettings, and watch its name before notifying on the
given task, so the mutter bits can proceed with X11 startup.
One notable change is that we only start gsd-xsettings, instead of the
generic gnome-session-x11-services target. We do so as we have to wait
on a dbus name to appear in order to deem the initialization done, and
making it all depend on gsd-xsettings seems tidier.
Less notably, we also use ::shutdown-xserver to shutdown the related
services. Its major benefit is that it'd allow us to ensure the olderly
shutdown of those services, but it's unused at the moment.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/836
When a window is being resized by the compositor, with Wayland the
compositor first asks the window to change its size and emits the
"size-change" signal, and then emits the "size-changed" signal after
the window acknowledges the new size. To show a fancy resize animation,
gnome-shell creates a "screenshot" of the resizing window on the
"size-change" signal, and later animates that "screenshot" to the new
window size on the "size-changed" signal.
Now if a client is not responding to our requests asking it to change
its size, we get a "size-change" signal and start showing the
window-clone, but never a "size-changed" signal, animating and hiding
the clone again. This causes a so called "ghost window" that is shown
above everything else and never disappears again.
To fix that, start showing the window clone once we get the
"size-changed" signal instead of the "size-change" signal. This makes
sure the window actually updates its size and the clone is going to be
hidden again.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1078https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1055
Creating a new GTimeZone for the local timezone can be quite expensive if
done repeatedly. It requires an open(), mmap(), and parsing of
/etc/localtime.
This patch was provided by Florian, and I've tested it as far back as
3.28.4 to ensure that we are really reducing the number of open() calls
on the compositor thread.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1051
Signed-off-by: Christian Hergert <chergert@redhat.com>
The g_file_replace_contents_async() API can potentially call fsync() from
the thread calling into it upon completion. This can have disasterous
effects when run from the compositor main thread such as complete stalls.
This is a followup to 86a00b6872 which
assumed (like the rest of us) that the fsync() would be performed on the
thread that was doing the I/O operations.
You can verify this with an strace -e fsync and cause terminal to display
a command completed notification (eg: from a backdrop window).
This also fixes a lifecycle bug for the variant, as
g_file_replace_contents_async() does not copy the data during the operation
as that is the responsibility of the caller. Instead, we just use a GBytes
variant and reference the variant there.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1050
Sadly, xgettext's dealing with template strings is abysimal, so we
had to stop using them in files with translatable strings.
Make sure we don't accidentally sneak in template strings again(*)
and enforce that rule in a CI job.
(*) easy "mistake", considering how much nicer they are than
String.prototype.format()
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
Also known as "Piotr Drąg Bot".
We will soon make sure that files processed by xgettext don't use template
strings. To make that check as adequate as possible, ensure that no source
code files are missing from POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
The thumbnails actor `this._thumbnails` has already been destroyed when
calling `_destroyThumbnails()` from the `destroy` signal handler because
it is a child actor of the AppSwitcherPopup. So stop destroying the
thumbnails separately (fading them out inside a destroy handler wouldn't
make sense anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
The correct property for the scroll-direction with scrolling events is
`direction`, no `scroll_direction`. This fixes scrolling in the alt-tab
popup, which broke with the actorization changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
When the switcherPopup was initiated successfully, we return true,
otherwise the WindowManager will try to destroy it. Since an early
release of the keystroke will also switch to another application and
close the switcher just fine, we should return true to indicate success
here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Right now the index that gets selected on click and motion events is set
when connecting the event inside the addItem function. If items are
added or removed (for example when an application is closed by pressing
"q"), this index isn't valid anymore and has to be updated.
To fix this, use the items themselves instead of the index as arguments
for the event handlers and lookup the index of the item inside the event
handler.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Set the accessible states of the switcherList items by calling a
function instead of manipulating class-internal variables from outside
the class, which is considered bad practice.
The check whether the item at `_selectedIndex` exists can also be
removed since we always select a new index after an item was removed
(i.e. an app was closed) and destroy the alt-tab switcher right away if
no more items exist (see `SwitcherPopup._itemRemovedHandler`).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Limit the minimum and maximum value to scroll to inside the box to 0 and
the upper limit, for some reason this was done right in _scrollToRight,
but not in _scrollToLeft.
This fixes the behavior of scrolling to the left: Before, scrolling one
item to the left moved the view to the first element of the list (this
can make the selected element invisible in large lists). Instead, scroll
one item to the left, just like scrolling to the right works.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Make sure the index that's being scrolled to doesn't change while the
scrolling animation is running by using an argument instead of the
this._highlighed class scope variable.
This fixes wrongly shown arrows when selecting new elements faster than
the scrolling animation takes for one index. The check run to disable
the arrow might be checking against a newer index than the one at the
start of the animation which results in the arrow not getting hidden
even if no more scrolling is possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Since this._highlighted is always set to the currently highlighted
index, there's no need to save the index to a separate variable. This
obviously depends on getting the new item highlighted as a result of the
item-entered event.
This fixes bugs in situations where the highlighted element changes
after an event that is not calling _onItemEnter, for example after
scrolling or pressing a key. In those cases the _currentItemEntered
variable wouldn't be updated and the old item couldn't be entered
anymore without entering another one before.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Visually the button is just an interactive label, so having the
interactive area extend to the empty space next to the label
is surprising.
Instead, left-align the whole button rather than just the label
inside, so the clickable area corresponds to the visible one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1046
The 'gdm' user is not going to run a media player, so there is no
point in allowing the corresponding section on the login screen.
All other sections are already disabled, so this is the only reason why
we end up with the message list instead of only showing the calendar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2241
This reverts commit c0c027c608. Because for
some reason animating external opacity and position is still incurring
internal repaints, which disables offscreening and makes fading of
overlapping actors look wrong. `ON_IDLE` should be fixed in mutter before
it is used (in boxpointer at least) again.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2270
While the old merge request URLs still work, gitlab recently started
including an additional /- for merge requests.
Adjust the regex to account for that, so that simply copying the URL
from gitlab works again.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1048
If the sessionMode does not allow to show the overview, we should also
hide an already visible overview.
This fixes a bug where, if the lockscreen was shown while the overview
was visible, the Ctrl+Alt+Tab popup would allow navigating inside the
overview because the overview actor is still mapped.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1043
If a transition is reversed, the final property values will be the
same as before the transition. However this currently only works
correctly when we actually use a transition; to fix this with a
duration of 0, simply skip the set() call when the transition is
reversed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1042
Commit 6c6c89c634 added a pill around the default avatar, but
assumed the sizes from the vertical widget used on the lock screen.
In order to fix the horizontal widget on the login screen, move the
size-specific bits to the corresponding .horizontal and .vertical
sections, and half the sizes for the former (which corelates with
the icon sizes).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2242
While the unread messages indicator is updated when starting a new
session because we call _onSourceAdded() on existing sources, we should
also update the do-not-disturb setting which might still be enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1037
Implement ClutterActorClass.has_accessible() to ensure that CallyActor does not
recreate accessibles during the removal/destruction of an actor. This relies
on GNOME/mutter!1083 for the ClutterActorClass.has_accessible virtual function.
Running GNOME Shell for about 30 seconds results in a difference between
the two runs.
Before:
ALLOCATED TOTAL FUNCTION
[ 52.2 KiB] [ 0.05%] cally_actor_real_remove_actor
[ 36.3 KiB] [ 0.04%] st_widget_get_accessible
[ 9.8 KiB] [ 0.01%] atk_gobject_accessible_for_object
[ 3.2 KiB] [ 0.00%] g_signal_emit_by_name
[ 2.9 KiB] [ 0.00%] clutter_actor_get_children
After:
ALLOCATED TOTAL FUNCTION
[ 1.8 KiB] [ 0.00%] cally_actor_real_remove_actor
[ 1.1 KiB] [ 0.00%] clutter_actor_get_children
[ 659 bytes] [ 0.00%] g_signal_emit_by_name
Obviously 50KiB isn't a huge savings.
Although fixing things to avoid re-entrancy on destruction can be very useful
from a correctness standpoint.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2263
We turned both the auth prompt's cancel button and the switch user
button into icon buttons now, which means they are completely cryptic
when using a screen reader.
Just use the previously used labels as accessible names, which has the
nice side effect of lowering the impact of the string freeze break.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
The button is hidden on the lock screen, so it shouldn't be allowed to
activate it, be it via click or keyboard. The latter is still possible
by keynaving to the button and hitting space/enter. Fix that by making
the button unfocusable when we make it unreactive.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
ShellStack implements custom focus navigation, and will only ever
navigate into its top-most child. That kind of makes sense as long
as that child is actually visible, but not when it is hidden.
Descend into the stack to look for a focusable child instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
Since commit mutter/a2a8f0cda we force the focus surface of the
meta-wayland-pointer to NULL while the pointer is hidden. This
introduced an issue with the magnifier, where we use
`set_pointer_visible` to hide the real cursor and show our own cursor at
the correct position: Because the meta-wayland-pointer is still used to
communicate with Wayland clients, the UI of the windows will not respond
to mouse movement anymore as soon as the real cursor is hidden.
To fix this, use the newly added clutter_seat_inhibit_unfocus() API to
temporarily disable unsetting the focus-surface while the magnifier is
hiding the system cursor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/993
If we are transitioning the label from 0 to its natural height, we
must set natural-height-set again after querying the preferred height,
otherwise Clutter would skip the transition.
However when transitioning in the opposite direction, setting the
property to true can go horribly wrong:
If the actor hasn't been allocated before, it will store a fixed
natural height of 0. But as there is no fixed min-height, we can
end up with min-height > natural-height, which is a fatal error.
(This isn't an issue when *actually* setting a fixed height, as
that will set both natural and minimum height)
So instead of always setting natural-height-set to true, restore
its previous value to fix the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2255
repeatCount and autoReverse don't play well with animations disabled:
They cause password entries to wiggle themselves off-screen (by ending
up with some off-scale translation-x value).
While we should handle this more gracefully in the transition helpers,
it also makes sense to handle the case directly in wiggle(): As it
uses a chain of three transitions, we would still end up with a crude
one-frame-per-transition wiggle "animation".
Instead, do no animation at all as you would expect when animations are
disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2236
Now that we apply a strong blur effect to the background, it doesn't
make too much sense to use a separate lock-screen background: It will
be mostly unrecognizable anyway.
The alternative would be to turn off the blur effect if a different
background is used (or have a hidden setting for that), but that would
then imply that we must keep the contents readable without blur.
Let's avoid that rabbit hole and just re-use the regular background.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1001
To bypass offscreening in cases where continuous animation is happening.
Offscreening is slower in such cases so this reduces the render time of
animations within offscreenable actors.
On an i7-7700 this reduces the render time of boxpointers for example by
25-30%.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1025
`-slider-handle-radius` is a floating point value and even in the default
theme it's not a whole number. Regardless of the fractional part that's
still going to occupy a whole extra pixel with antialiasing. So make room
for it. Otherwise it looks clipped, which it is by the Cairo context of
its `StDrawingArea`.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Unused at the moment, but add the plumbing so that default key
definitions may specify symbolic icons that will be shown instead
of the text.
This is intended to replace the use of CSS and background-image
to handle those buttons with an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2214
While the gsetting is available for all who needs it, the Shell might
override it given various hueristics. Expose the decision made by the
Shell via a new property.
Intended to be used by gsd-xsettings as well as xdg-desktop-portal-gtk.
This also add a version property to the API, so that semi external
services (xdg-desktop-portal-gtk) can detect what API is expected to be
present.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/757
For reasons not yet fully understood, `Main.uiGroup.add_actor` takes around
10 milliseconds to complete.
Because of this, each `actor.opacity = 0` has a good chance of falling
on a different frame. And when it does, `_opacityChangedId` also lands
on multiple different frames each incurring a separate relayout cycle.
It is this excessive number of relayouts that causes stuttering in the
icon grid animation (#2065). But it is the slowness of `uiGroup.add_actor`
that causes the number to be excessive when it should be one.
By creating the clones and adding them to `uiGroup` early, we then enable
the existing loop starting the animation to complete within a single frame.
And by completing within a single frame all the opacity changes land within
the same frame interval, thus incurring only a single relayout instead of
many.
This issue went unnoticed until 004a5e1042 (!704), after which the slow
emissions of `notify::opacity` became a more visible performance problem.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2065https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1002
Now that the bind constraint changes the preferred size of
the actor, a major flaw in the AppDisplay code was exposed:
the folder dialog depends on the preferred size of a parent,
and the parent depends on the preferred size of the folder
dialog.
While we know this is not actually true, we shouldn't rely
on broken behavior to achieve this result. What's interesting
is that the bind constraint used by the folder dialog is a
relic of the development phase; we now control the position
and size of the dialog with a combination of CSS, and alignment.
Remove the unnecessary bind constraint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1027
Since the design of the notification popup changed with the theme
refactor and there are now boxes around the world-clock and weather
sections, the overlay scrollbar that is shown above them looks rather
bad. So simply hide that scrollbar, we still have the vfade effect to
indicate the container is scrollable and we also depend on that in the
new popup app-folders.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1013
Make sure the stylesheet properties of the window-chrome title are
updated before requesting the preferred width of the title to prevent
size changes of the title after we animated the width.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/58
Remove the default icon size of -1 and always set the container StBin to
a real size. This fixes an error where the "width" and "height"
properties get set to -2 (which is -1 * scaleFactor) in the `_init`
function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1018
To make sure the GC really disposes the KeyboardController object we
need to remove all references to the object, which means we have to
disconnect signals the object connects to, too.
This also fixes a bug where keys remain pressed forever and thus also
break that key on real keyboards. It happens if the OSK gets destroyed
during an OSK-key is being held so the StButton of the key is not
released. That means the key remains pressed in the
MetaVirtualInputDevice that we are now leaking because
KeyboardController isn't garbage collected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1015
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since quite a few strings of dialogs provided by external programs are
not updated yet and the string freeze is already in effect, make sure we
don't break those dialogs by stripping aways large parts of the
headline.
To do that, detect if the title label is larger than the available width
and if it is, switch to a smaller font-size of 13pt. This makes sure we
still show about the same number of characters in the headline as we did
in previous releases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1012
With the old screen shield, we were simply hiding the lightboxes to show
the shield when the user became active after activating the shield but
before locking the screen (that is, when using a lock-delay).
However now that the shield is gone, we end up showing the unlock dialog
even though we are not actually locked.
We probably don't want to add back a shield-like mode (that is, a way to
raise the unlock dialog without authentication when we aren't locked),
so just deactivate the whole shield when the user becomes active again
before the lock kicks in.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2213
The design team discussed the ellipses at the end of the hint text of
our entries and, even though they are present in most mockups, it turned
out they don't like them, so remove them.
It also turned out they don't like the prefixes like "Enter" before it,
so remove those, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
With the new dialog design the descriptions of entries are now
implemented as hint-text of the StEntry. That means the colon at the end
of the descriptions no longer makes sense and should be removed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
Currently separators get all the padding from regular menu items,
which is excessive for non-interactive elements.
Shuffle style classes around a bit to allow overriding the normal
padding for separators.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1004
Shift, caps-lock and friends change the capitalization of following
key presses. It is unexpected for those keys to have side-effects,
so don't switch to the prompt when they are pressed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2215
We don't want to show a caps-lock warning when showing a non-password
entry, but we also don't want the layout to jump when changing the
label's visibility.
Achieve that by inserting an empty placeholder label that we can
show whenever the caps-lock warning is hidden.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2215
The promptBox is initially fully opaque, so showing it before the
transition can result in a brief flash before fading in.
Just remove the show() call and let the transition handle the
visibility.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2212
Usually, logging in or unlocking the session is made asynchronously,
and AuthPrompt properly manages which entry is currently visible.
External code don't rely on any specific entry to be set, since it
is AuthPrompt's responsibility to select the correct one to be shown.
However, there's one specific case where AuthPrompt must preserve
the password entry: on reset. The reset code preserved whatever
entry was currently displayed, but after fe69dacaf1, it always
changes to the username entry.
Make sure to show the password entry on reset.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the past, the session menu button was part of the auth prompt widgetry,
so we didn't have to manually hide it when showing the user list. However,
now it is part of the login screen itself.
Hide the session menu button when the user list is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the common case where we only have a single unread notification
from a particular app, the count doesn't add useful information.
Reduce clutter a bit by only showing the notification count if we
have at least two.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/997
Instead of alphabetical ordering, sort the widget stylesheets
from more global to more local while grouping related things.
This helps reduce unintended behaviors and ugly overrides and
make styling and debugging easier.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/938
Clicking or typing to reveal the auth prompt are good options for
mouse/keyboard workflows, but awkward on touch devices. Now that
we have SwipeTracker, adding corresponding gestures support is
easy, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
The current transition between clock and auth prompt uses a simple
crossfade.
"What kind of spatial model is that?!"
T.B.
Root the transition a bit more by adding translation and scale to
the animation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
Hiding the Caps lock warning label changes the layout of
Auth Prompt. This is specially noticeable when logging in
with unlisted users, where we change the visibility of this
label after typing a username, and the whole user widget
moves a bit.
Change the Cap lock label's opacity instead of hiding it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, when a null user is passed, we don't add any
username label. That makes the layout of user and no-user
cases inconsistent.
Add a ghost label with no opacity to mimic the username
label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, AuthPrompt is connecting to its own 'next' signal
signal to react to any of the entries being activated, and do
some actions like starting the spinner and answering the PAM
question.
Refactor this code into another method, and don't connect to
our own signal.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Unfortunately, the question that is displayed comes directly
from PAM. It usually is just "Password:", which comes from
pam-unix, but other questions can be set, usually with the
colons, since they are crafted with a CLI workflow in mind.
Manually drop the colons from questions asked by PAM. This
is also done by the PolKit agent, which shows how the stack
is fragile, but it's what we have for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
This is a regression from the transition to password entry. Both
entries need to be connected to the relevant signals, otherwise
username-based login won't ever work.
Connect both the text and the password entries.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, there is a dedicated label above the entry to
display the question text. According to the new mockups
for the lock screen, this label doesn't exist; instead,
the question is set inside the entry itself, as a hint
text.
Set the questions as hint texts of the entry, and remove
the now unused label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
If username-based login flow is followed, we need a default avatar
for the userWidget. Hence, check if the user passed to userWidget
is (null) which implies a username-based login flow.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Allow vertical orientation for the userWidget so that the user-avatar
can be centered and user's name can be placed below it. The plan
for 3.36 is to use this vertical userWidget layout for both lock
and login screen.
The userWidget is also used while creating the user-selection list
at the login, hence we still need to keep the horizontal layout
for userWidget in place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Since the blur sigma decides how many pixels get factored in when
blurring and setting a scale factor increases the background texture by
that factor, the sigma value should also be multiplied by the scale
factor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
If we modify the paint volume to make it larger and include the blur
radius, we should also use the gained size and draw something there.
Since the framebuffers are only the size of the actor to blur, we're not
doing that right now anyway, so remove the vfunc override.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Use the shader for linear sampling and incremental calculation of the
gaussian kernel values as it was implemented by Patrick Walton in
webrender.
The sigma value for the blur (the standard deviation) is calculated by
taking the blur radius and dividing it by 3, this value is used by most
implementations of gaussian blurs since it covers a high percentage of
the gaussian shape.
The linear sampling optimization is implemented by skipping every second
texel (i += 2) in the for-loop that's sampling adjacent texels.
https://github.com/servo/webrender/blob/master/webrender/res/cs_blur.glsl38ec7db6f1https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Floor the downscaled size of the new framebuffer to make sure we don't
initialize a framebuffer with a floating point value that might be
interpreted wrong by `cogl_texture_2d_new_with_size` and end up with a
slightly wrong aspect ratio of the framebuffer.
This fixes situations where the widths or heights of downscaled
framebuffers sometimes miss some pixels at the border.
While at it, remove the `downscale_factor` argument from
`setup_projection_matrix` since that function doesn't need the initial
size of the actor anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Now that we support extension updates, it may be useful to list
pending updates from the command line. It's easy enough to support,
so add a corresponding option to the list command.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/988
There is nothing else to be focused in the lock screen itself -- the
top bar is already handled elsewhere, and the dialog manages itself
now.
Remove the lock screen group from the Ctrl-Alt-Tab manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
AuthPrompt is the set of actors that contain the user avatar,
the username, and the password entry. With the removal of the
screen shield, the unlock dialog (be it UnlockDialog or the
LoginDialog) is always created, and in the case of UnlockDialog,
so is the auth prompt.
This is problematic, though, since for passwordless accounts,
the simple act of creating AuthPrompt authenticates the user,
and lifts the lock screen.
Create the AuthPrompt on demand in UnlockDialog.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
As per the latest lock screen mockups, critical notifications must have
a more prominent, solid color.
Add a .critical style class to critical notification bubbles, and make
them darker.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Now that the screen shield is gone (at least, as it used to
be), the corresponding session mode is not necessary anymore
as well.
Remove the 'lock-screen' session mode, and the corresponding
CSS.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Pretty much what the commit title says.
This gives the lock shield actor another role: instead of
being the interactive screen shield, make it the invisible
actor that prevents interacting with windows while the
unlock dialog is sliding down.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Activating a dialog is slightly different from opening it; the
former is about showing the user authentication widgetry, while
the latter is about creating it and pre-allocating the necessary
resources.
Activate the screen shield dialog when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The 'onPrimary' argument was being passed to dialog.open(). Turns out,
neither UnlockDialog nor LoginDialog use this parameter.
Remove the unnecessary 'onPrimary' parameter, and cleanup the related
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The use of the core idle monitor means that focus change events
are also delayed by keyboard interaction. Since the magnifier is
already in the business of pointer tracking, it's easy enough to
fire the pointer rest timeout from here, so focus changes are
accumulated and delayed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
We may get several a11y events setting the caret on the same
coordinates it previously was. Make focus tracking ignore those,
as we're jumping to the same coordinates again during eg. mouse
operation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the crosshair is clipped so it doesn't cover the pointer cursor,
the clip rectangle is skewed towards the bottom/right. This was
made so to accomodate the default pointer, but the unevenness stays
on other pointer cursors, and it makes the crosshair look odd on
short crosshair length.
Make all lines clip to an even distance from the center instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
It is somewhat unexpected that crosshair color and pointer cursor colors
remain the same across changes in color inversion settings, and may lead
to contrast issues. Apply the effect on the common container, so it
applies to these all.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the icon proper has opacity of zero then that's probably because a
clone of it is animating. So avoid animating the source actor too.
And if there's any other reason for the opacity being zero, still don't
animate it because we can't see it :)
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2167
So as to guarantee the unmapped state sticks and doesn't get toggled
back to mapped before we return.
Being in a mapped state when `FolderIcon.vfunc_unmap()` returned was
causing an assertion failure in `clutter_actor_set_mapped` and crashed
the shell.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2170
The inconsistent styling rules "some card styles are nested, but some
are not" and "some card styles are nested, but some of their descendant
styles are defined elsewhere" are very confusing.
This commit stops nesting all card styles to make the coding style
consistent and less confusing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/957
- Remove bottom blank space on the right column of the calendar popover
so that the weather card is bottom-aligned with the clear button on
the left column.
- Remove top blank space on the left column of the calendar popover so
that the message list is top-aligned with the today button on the
right column.
- Adjust .message-list-controls sizing to align with other card-styled
elements.
- Use regular `spacing` instead of margin for some spacing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2088
Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2120
- Use fewer properties for layout.
- Use .message-body instead of .message-content to change the body
color, and remove some color overrides.
- Fix border-radius for last .message-media-control, not only on hover.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/957
- Remove margin-bottom for StIcon, which is not only ineffective, but
also created a bug in app folders.
- Remove ">" which is invalid for overview icons that are not app
folders.
- Apply spacing to the correct target "StBoxLayout", not the parent
.overview-icon.overview-icon-with-label.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2129
The used_scales hash table uses g_double_hash and g_double_equal which
try to read a double from the passed pointers. The pointers however were
pointing to a float, leading to an invalid read.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/974
The portal helper is rather sensitive because potentially-hostile Wi-Fi
networks can decide to launch it whenever they want (by blocking the
user's connection to the nmcheck domain) and load whatever web content
they want into it. So having this unsandboxed is really extraordinarily
risky. Previously it was a risk we had to accept, because WebKit did not
have a web process sandbox, but now it does. So let's bubblewrap all the
things!
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/983
- the plan was to drop the frequent/all view switcher, thus sam didn't
pay too much attention to the button styling for those. Sadly the view
switcher remains, so we should keep the old subtle styling intact.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/979
Commit 147a743d8d moved the suspend and power-off actions into
the submenu that contains the log-out and switch-user actions,
but did not update the submenu visibility logic to account for
the additional actions.
As a result, the submenu is hidden when log-out and switch-user
are unavailable (like on the login screen), even if suspend and
power-off are enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2169
While gnome-shell will now check for extension updates, the checks
are performed infrequently. Opening the Extensions app implies that
the user's current focus is on extensions, so it is an appropriate
time to schedule another updates check.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we can download, apply and display extension updates, it is time
to actually check for updates. Schedule an update check right on startup,
then every 24 hours.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we have support for extension updates in the shell, we
need some place to display the updates to the user.
As we are establishing the Extensions app as the primary way for
managing extensions, it's a natural place for that functionality.
Show which extensions have updates available, and offer a log out
button (so gnome-shell can apply the updates when logging back in).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Until now, it didn't matter whether an extension was installed in the
user's home or system-wide. However with support for uninstallation,
there is now a significant different, as that action is only available
for user extensions.
Account for that by separating extensions by type, so that users don't
have to second-guess which extensions can be fully-managed and which
appear as part of the system.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The newly added expander gives us a place where we can display
more details without cluttering the interface.
Take advantage of that by including the extension website, version
and author.
(Author is in the mockups, but will not actually be shown until
the extensions website is changed to include it in its metadata;
however best to have UI and string in place for the freezes)
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The description can be useful information, but also increases the
visual complexity of the extensions list. Move it into a hidden
details area that can be expanded, which unclutters the interface
while keeping the information readily available.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The current fixed two-line label requires a custom widget, which
make moving to a widget template harder.
As the description will soon move elsewhere anyway, just go back
to a single line with a standard label for now.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Extensions can have a major impact on stability and performance. Now that
the tool will become the main way for users to manage their extensions, it
is an appropriate place to warn the user of that risk.
Add a small info popover to the headerbar to display that warning, together
with the previously removed hint of where to go for finding new extensions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently when the extensions list is scrolled, it is possible to
keynav out of view, as the scrolling doesn't follow the key focus.
Hook up the adjustment to fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently the main window is a plain Gtk.ApplicationWindow that is
built and managed from within the application.
As the application becomes more complex, it makes sense to decouple
the two and handle the window from a separate ExtensionsWindow class.
Not least this is a prerequisite of using a widget template for the
window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
GNOME Software will remove its extension support, so we should stop
referencing it in addition to extensions.gnome.org.
In fact, the placeholder is not the best place to hint at where new
extensions can be found, as the user will never see it in case the
distribution includes pre-installed extensions.
So remove the hint altogether, we will add it back in a more prominent
place later.
With the whole placeholder now being much lighter, we can stop dimming
the remaining elements.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
If all password entries in dialogs are hidden, there is either an entry
that has visible characters or no entry at all. That means we don't have
to show the caps lock warning at all, so hide it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the headlines of the dialogs now use a much larger font, the
strings need to be shorter so they won't be ellipsized. So use a shorter
strings for those titles and also adjust the title-strings of the
notifications sent by the NetworkAgent to be consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the wiggle effect will be used by the redesigned prompt-dialogs
and we always want to use the same parameters, move those as defaults
for the wiggle function to the util.js file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the caps-lock warning adds a lot of spacing to dialogs and the
lock screen, hide it by default and only show it when necessary. To make
the transition smooth instead of just showing the label, animate it in
using the height and opacity.
Also add some bottom padding to the label so we can show or hide that
padding, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The caps-lock warning is more related to entries than dialogs and is
also used in gdm, which is not realated to dialogs at all. Rename the
css class to caps-lock-warning-label and move it to the entry
stylesheet.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The Animation class inherits from St.Bin and manages the scale factor
in the image loading, but the widget size doesn't change and doesn't
depend on the scale factor so when the scale factor is different
from 1 the widget size doesn't match the image size.
This patch resizes the Animation widget using the scale factor so the
widget will match the animation images sizes.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1746
Now that we have a way to check for updates and download them, we
should actually apply them as well. Do this on startup before any
extensions are initialized, to make sure we don't run into any
conflicts with a previously loaded version.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
While it is possible that an extension has a newer version available
than the previously downloaded update, it's more likely that we end up
downloading the same archive again. That would be a bit silly despite
the usually small size, so we can either use the metadata from the
update, or exclude the extension from the check.
The latter is much easier, so let's go with that for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
Currently the method installs updates instead of merely checking for
them (or it would do, if it actually worked).
This is not just surprising considering the method name, the whole idea
of live updates is problematic and will not work properly more often
than not:
- imports are cached, so any local modules will stay at their
original version until a shell restart
- GTypes cannot be unregistered
So change the method to only download available updates, and set the
extensions' hasUpdate state accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
The current support for extension updates is half-baked at best.
We are about to change that, and implement offline updates similar
to gnome-software.
As a first step, add a hasUpdate property to the extension state
which will communicate available updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
Since a11f417cd0, both drag and scroll
gestures are added to Main.layoutManager.overviewGroup actor, while
previously drag gesture was added to Main.overview._backgroundGroup
instead. Since we cannot use 2 different actors for dragging and scrolling
anymore. just disable the swipe tracker while dragging a window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2151
Since the orientation lock menu entry is a proper menu entry instead of
a icon-only button now, we also show a description-text for that entry,
so update this text depending on whether orientation is locked or not to
better reflect what clicking the menu entry will do.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/964
Since we don't really know what the buttons we're adding to the dialogs
are about, we can't configure a button to "be clicked" when the escape
key is pressed. So add a separate escape key handler to fix that, return
-1 and abort the request.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
When updating the buttons of the mount dialogs, compare the new buttons
to the old ones and only create new buttons in case something changed.
This makes sure key focus isn't reset or lost unnecessarily while a
dialog is opened.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
Since there is a generic layout for dialogs like that now, use it. Also
remove the functionality of focussing a window when clicking a list
item, it's not discoverable at all and pretty unexpected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
`gnome-shell-perf-tool` is initially designed to run on X11, using the
`--replace` option which does not work when gnome-shell is a Wayland
compositor.
A solution would be to run `gnome-shell-perf-tool` in place of just
`gnome-shell` to run the entire perf session under Wayland, but the
script `gnome-shell-perf-tool` does not spawn `gnome-shell` as a Wayladn
compositor, so that fails as well.
Add a `--wayland` option to `gnome-shell-perf-tool` so that it can
optionally spawn gnome-shell as a Wayland compositor so the whole perf
tool can be starred from a console with:
```
$ dbus-run-session -- gnome-shell-perf-tool --wayland
```
Alternatively, for testing purposes, it can also be started nested with:
```
$ dbus-run-session -- gnome-shell-perf-tool --nested
```
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2139https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/941
On Wayland, the display server is the Wayland compositor, i.e.
`gnome-shell` itself.
As a result, we cannot spawn `gnome-shell-perf-helper` before
`gnome-shell` is started, as `gnome-shell-perf-helper` needs to connect
to the display server.
So, instead of spawning `gnome-shell-perf-helper` from the perf tool,
start it from `gnome-shell` itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/941
For window-backed apps (read: windows we can't match to a .desktop
file), we use the window's icon property as icon. However there is
no such property on wayland (at least in the protocols we support),
so we end up with a blank actor in that case.
Do better than that, and pick a generic fallback icon instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1779
Notifying the "text" property inside `st_entry_set_text()` misses all
the text changes done by ClutterText itself, including those that happen
on key-presses. Fix that by notifying that property inside the
"notify::text" handler connected to the ClutterText.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/951
Also show the hint actor of an StEntry while the entry is focused but
has no text inside it. This is part of the new dialog and lock-screen
design where there are no labels before entries anymore and labels are
instead shown as a hint-text of the entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/944
set_fallback_icon_name() leaks a GIcon by using the set_icon method
which adds a ref to the GIcon without removing its own ref after calling
the method.
Related to https://gitlab.gnome.org/GNOME/gnome-shell/issues/2146
When do-not-disturb is enabled, non-critical notifications will not
be shown as banners. It therefore makes sense to indicate that state
to the user, so they don't accidentally miss notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
Currently the indicator pad requests a size of 0x0 if the corresponding
indicator is hidden. Right now this is enough to balance out the indicator,
but it won't be when we add spacing to the parent container.
Properly hide the pad with the indicator to avoid that issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
We've had the ability to temporarily disable notification banners
all the way back to 3.0, but we stopped exposing it in the UI with
the 3.16 notification redesign. With the message list being more
concise nowadays and the "Clear" button reduced to a single icon,
we now have space for a "Do Not Disturb" switch again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
We try to make the OSK 1/3rd as big as the monitor. On landscape
layouts we usually get away with it as there's plenty of horizontal
space to enlarge the OSK while keeping the OSK aspect ratio.
In portrait layout, the horizontal space is a lot more scarce so
it means we'll still have plenty of space after making the OSK as
wide as it can possibly be, which will look as odd blank space in
the OSK panel.
In order to fix this, let the OSK panel height be less than 1/3rd
the monitor size if we are dealing with portrait layouts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2132
It will happen before next map anyway, and most notably at times
actor sizes produce correct results.
Fixes oddities in emoji pager visibility after showing the emoji
panel, moving to another page, and hiding the OSK with the downward
arrow button. The next time the emoji panel would be shown, panels
had a chance to remain invisible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
It is already scheduled to be set on first map. Doing so here triggers
size and theme node checks the actor tree is not ready for, as the
toplevel actor is not yet attached to the stage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
This functionality always suffered from discoveribility
problems, and now that the folder dialog can rename the
app folders, there's just no reason to keep it.
Remove the rename popup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Now that the folder dialog handles the adaptToSize workaround,
there is no need to propagate the call throughout the class
hierarchy.
Remove the propagating calls to adaptToSize, and all the satellite
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Now the the folder popup behaves like a dialog, it must be
above the app grid, and not be affected by the scroll view
translation.
Add the folder popup to the AllView itself, instead of the
internal Shell.Stack that is inside the scroll view.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Make the AppFolderPopup behave much more like a dialog than a
popup itself. To do that, remove the BoxPointer and replace it
by a StBoxLayout. The dialog is is also bind-constrained to the
view selector.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
St has the regular abstractions to handle actors that are bigger
than their parent could handle: StScrollable, StScrollView, and
StAdjustment.
However, the only StScrollable implementation available currently
is StBoxLayout, which forces a ClutterBoxLayout as the layout
manager (and relies on it not being unset).
Introduce StViewport, which is a minimal StScrollable implementation
that doesn't rely on any specific layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/929
Since the overview search results now have a dark background layer, we
can brighten the background image a bit again. As a factor we use 0.5,
since that ensures the texts in the IconGrid are still readable and the
background image is visible, too.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2133
If a new SwitcherPopup is created and there are no windows or apps to
switch through found, instead of returning from _init(), still
initialize the SwitcherPopup and let the check in SwitcherPopup.show()
return false to terminate the popup.
In both cases, with or without the return statements,
WindowManager._startSwitcher() will call SwicherPopup.destroy(), which
will try to disconnect signal handlers, destroy actors etc. Now if the
constructor can't finish creating the popup, some of the functions
called from _onDestroy() will fail and throw errors.
One of those cases is when window-switcher is limited to the current
workspace, and a WindowCyclerPopup is initiated on an empty workspace.
Because this._highlight hasn't been created, _onDestroy() will fail when
trying to destroy the actor of this._highlight.
Also, the actor of this._switcherList will not get destroyed in case
show() returns because this._items is empty. For example, this will
happen when a new AppSwitcherPopup is initialized with at least 1
running app, but 0 windows on the active workspace.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/168
Instead of removing all button shadows forcibly with
`box-shadow: none !important`, remove only the drop shadows selectively
with button(). This allows %bubble_button to preserve the focus ring
while eliminating the drop shadows.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2088
- Move the more generic %button style before %bubble_button to reduce
ugly overrides.
- Remove sizing factors from _drawing.scss to reduce ugly !importants.
- Make the %bubble_button style more consistent.
- Add missing focus styling to %notification_bubble.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/931
When pressing the menu key to show the popupMenu inside a ShellEntry,
the menu is currently aligned with the end of the entered text, this
causes a bug in case the text is overflowing the width of the entry: The
menu will be shown outside of the entry field, because it's aligned with
the (invisible) end of the text.
Fix that by simply aligning the popup menu with the cursor of the entry,
which is a behavior that makes sense when pressing the menu-key anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/934
`MessageDialogContent.messageBox` is not really needed and was only
needed to show icons, which is now no longer supported. The styling can
also be done using other CSS classes and this makes it a bit more
straightforward to add actors to the MessageDialogContent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/886
Since MessageDialogContent.messageBox is going to be removed in a
subsequent commit, move the parts where it's used out of messageBox and
into the contentLayout instead. This will introduce wrong spacings in
some dialogs, which we're going to fix when implementing the redesigned
individual dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/886
Since the last commit we set the gicon property of StIcon to NULL if an
empty string was given when setting the icon name, this means
`st_icon_get_icon_name()` will return NULL instead of an empty string.
When `getIndicatorIcon()` returns an empty string, the icon_name
property will now be set to NULL, so compare it to NULL here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/888
Don't try to create a GIcon if the given icon name is empty, it will
lead to failure when loading the icon anyway, instead set the gicon to
NULL just as we do in the `set_gicon()` API when unsetting an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/888
Animating the icon spring using the `translation-x/y` properties instead
of the `x/y` properties avoids relayouts. There are still other non-icon
actors moving, but it's a big improvement.
Before: 595 relayouts per spring
After: 94 relayouts per spring
Reducing relayouts reduces reallocation, which reduces CPU-intensive
JavaScript execution.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/926
String.prototype.substr() doesn't support a negative length value
(to subtract from the full length), so we end up with a filename
of '' when hitting that code paths (a relative filename with '.png'
suffix).
Fix this by switching to String.prototype.replace() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2091
Replace existing panning and touchpad scrolling by SwipeTracker.
Since SwipeTracker only references one actor, redirect scroll events
from page indicators to the main scroll view.
Change programmatic scroll animation to use easeOutCubic interpolator
to match the gesture.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/826
Add a unified swipe tracker supporting dragging, four-finger swipe on both
touchscreen and touchpad, and touchpad scrolling.
The shared logic is largely same as the one in WebKit and libhandy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/826
Commit 24e631ffe2 changed the shield animation to use translation
instead of position.
However once the shield is raised, only an animation will lower it
again, which means the shield is missing when it's supposed to be
shown without animation (for example after an idle blank).
Fix this by resetting the translation-y property in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/927
The brightness property of ShellBlurEffect is of float type, but
we are calling g_value_set_int() in the GObject::get_property()
handler, which throws warnings when trying to set the property
via g_object_set() and family.
Use g_value_set_float() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/924
Together with the forecast icon, the temperature label is the most
important information in the weather section. To emphasize it more,
reduce its space requirement by removing the temperature unit, then
make the text bold.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1143
- panel fg color was derived from bg color. Not a good idea as it's not
just light/drk, but HC as well.
- deriving from dark theme means contrast for things like popover items
is better.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/904
Since commit 90a08ba0b6, we only open a network secret dialog immediately
in response to user action, and show a notification otherwise.
While for the actual request VPNs are handled separately from other connections,
this isn't true when we show the notification - we need to handle 'vpn' together
with the other types there, or we fall through to the default 'invalid type'
exception.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2008
Now that both ThumbnailsBox and WorkspacesDisplay use single adjustments for
controlling indicator and scrolling, create the adjustment in OverviewControls
and pass it to both objects, effectively syncing indicator to scrolling.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
Instead of having a scroll adjustment in each WorkspacesView, and using the
one from primary screen in WorkspacesDisplay, have just one adjustment in
WorkspacesDisplay, and sync the changes between WorkspacesView.
This will allow to share the adjustment between WorkspacesDisplay and
ThumbnailsBox in the next commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
Instead of using the 'y', which queues a full relayout and
thus forces effects to be reapplied, use the 'translation_y'
property, that doesn't force relayouts and allows a future
blur effect to actually use the cached framebuffers a lot more.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864
This is a moderately fast two-pass gaussian blur implementation.
It downscales the framebuffer dynamically before applying the
gaussian shader, which cuts down rendering time quite considerably.
The blur shader takes 2 uniforms as input: the blur radius; and
whether to blur vertically or horizontally.
The blur radius is treated as an integer in C land to simplify
calculations. The vertical parameter is treated as an integer by
the shader simply due to Cogl not having proper boolean support
in snippets.
At last, brightness is also added to avoid needing to use an extra
effect to achieve that. Brightness is applied in a different pipeline
than blur, so we can control it more tightly.
ShellBlurEffect also implements a "background" mode, where the contents
beneath the actor are blurred, but not the actor itself. This mode is
performance-heavy.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1848https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864
Many of the apps in the favorite apps list have fallen out of favor.
Replacing Rhythmbox with Music and Shotwell with Photos are obvious
moves. Rhythmbox and Shotwell are not core apps, and that means we
assume they are not installed by default. It doesn't really make sense
to have non-default apps in the apps list.
Evolution is also not a core app, and that is not likely to change, so
it should also be removed. Adding Geary might be more controversial. It
is a strong candidate to become a core app, GNOME Mail, in the near
future, but it is not there yet. So this could arguably be considered
premature. But I figure a GSettings
default is a cheap thing; we can always change it later if desired.
Calendar is added at the request of GNOME design team ("replacing" the
calendar functionality of Evolution).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/907
This is what most GNOME modules now use instead of a shell script,
which makes sense given that the build system itself is written
in python.
This particular copy comes from nautilus ...
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/920
In an earlier iteration of the ease patch set, animatable properties
and easing parameters were different arguments.
This wasn't the case in the final version, so remove the left-overs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/917
We don't want the icon to fill extra space, so set the alignment
accordingly. Otherwise we get an unexpected result when adding
a background just to the icon part (as far as I can tell: just
system-action-icon).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/909
StScrollViewFade depends on st-scroll-view-fade-generated.c, but
that dependency isn't expressed to the build system; we just hope
that the custom target runs before compiling the effect.
Instead, add the generated source to the st target so the dependency
is expressed properly.
(The change from .c to .h is to prevent the file from being both
included and compiled, resulting in a duplicated symbol)
https://bugzilla.gnome.org/show_bug.cgi?id=789937
The screenshot code has a fair bit of nested callbacks, which means
that it is a good use case for async functions and Promises.
Most code uses GIO's async pattern, which means it can be easily turned
into promises with Gio._promisify(); first handle the couple of cases
that need custom code though, starting with SelectArea.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/903
Some GrabHelper uses are in the form:
doPreGrabStuff();
this._grabHelper.grab({
onUngrab: () => {
undoPreGrabStuff();
},
});
A promise-based variant allows to write this more cleanly as:
doPreGrabStuff();
await this._grabHelper.grabAsync();
undoPreGrabStuff();
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/903
We currently handle the case where the indicator itself is disabled
(read: hidden), but not when the entire top bar is invisible (for
instance when the primary monitor is in fullscreen state).
It is odd to pop up a top bar menu without the top bar, so check for
the indicator's mapped- instead of visible state.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2002
After creating a new extension, we try to open the main source
file with the default handler, which fails when there is none.
But given that the extension was created successfully, don't treat
a missing handler as failure, and print the path to the new extension
instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/905
Epiphany and Evolution updated their desktop IDs years ago. I assume the
rename list in appFavorites.js ensures this is still working properly
despite the obsolete names.
While we can now build gnome-extensions-tool as stand-alone project,
we are currently missing any translations, as those are part of
gnome-shell.
The easiest option for addressing this would be to symlink the toplevel
po directory into the subproject, however that would mean duplicating
the entire gnome-shell message catalogs.
So instead, set up a bare po directory and provide a script to populate
it from the translations in the toplevel po directory.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
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
The file was generated when importing gnome-extensions-tool from
a standalone repository. It isn't used by the build system, and
really shouldn't have ended up in the repository at all.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
Also introduce a "show-peek-icon" property to enable/disable
the peek-password-icon in the password entry. This is useful
in cases where the peeking the password functionality needs
to be avoided.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
This frees the entry's secondary icon that for other uses.
Caps-lock-warning feedback has been moved to be shown in
the various dialogs instead in the password-entries itself.
StPasswordEntry can now use a peek-password icon as the
secondary icon to show/hide the password present in the
entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
Use the new StPasswordEntry for password entry fields
and remove all direct handling of clutter text of the entry
via clutter_text_set_password_char to show/hide the password
text. StPasswordEntry will provides a peek-password-icon which
will allow to show/hide the password present in the field to
the user in subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
shellEntry should not need to query the clutter-text directly
in order to know if the entry is for passport-input purpose.
shellEntry can easily determine a password-entry by querying
if it is an instance of StPasswordEntry and use it's API
whereever relevant.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
StPasswordEntry will be put to use for password entries
in various shell dialogs. This is done to have a consistent
behaviour for all password entries and introduce a peek
password functionality for these password entries in the
subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
d="m 148.00015,821.0002 h -1 c -0.26528,0 -0.53057,-0.093 -0.71875,-0.2812 l -3.71875,-3.7188 c 0,0 2.47917,-2.4792 3.71875,-3.7187 0.18817,-0.1882 0.45344,-0.2813 0.71875,-0.2813 h 1 v 1 c 0,0.2653 -0.0931,0.5306 -0.28125,0.7188 l -2.28125,2.2812 2.28125,2.2813 c 0.18811,0.1881 0.28129,0.4534 0.28125,0.7187 z"
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:'Bitstream Vera Sans';-inkscape-font-specification:'Bitstream Vera Sans';text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-anchor:start;display:inline;overflow:visible;visibility:visible;fill:#bebebe;fill-opacity:1;stroke:none;stroke-width:2;marker:none;enable-background:accumulate"
d="m 189.0002,759.4375 -5.71875,-5.7187 C 183.08558,753.5229 183.0002,753.2556 183.0002,753 v -1 h 1 c 0.25562,0 0.52288,0.085 0.71875,0.2813 l 4.28125,4.2812 4.28125,-4.2812 C 193.47732,752.0854 193.74458,752 194.0002,752 h 1 v 1 c 0,0.2556 -0.0854,0.5229 -0.28125,0.7188 z"
<property name="label" translatable="yes">We’re very sorry, but there’s been a problem: the settings for this extension can’t be displayed. We recommend that you report the issue to the extension authors.</property>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
