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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
This is necessary to make DnD operations work from tablet devices on
wayland, as it's not the same onscreen pointer sprite than mice. Fixes
window DnD in the overview on tablet devices, no longer having them stick
to the wrong pointer.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/897
Just like switcher popups, popup menus don't play well together with
system modals, and generally have a lower priority. So just like
switcher popups, close popup menus when a system modal dialog pops
up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1536
As system modal dialogs may open without user interaction (for instance
polkit or network agent requests), it is possible for them to pop up
while the app/window switcher is up.
The current result of having both up simultaneously is clearly broken,
so we can either dismiss the popup or prevent the modal dialog from
opening. Assume that the dialog indicates a more important action and
should therefore take precedence, so go with the former.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1536
Since both the `_items` object and the `_allItems` array include the
same items, the difference between those variables seems unclear. The
real difference between them (except the different data type) is that
`_allItems` is ordered in the same order as the visible grid, so rename
`_allItems` to `_orderedItems` which makes that more obvious.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/799
The icon grid currently sorts icons by their names. When creating new
folders, the folder may end up being in a different page, and that's
confusing since we don't actually move to where the new folder is.
Move the icon grid to the newly created folder.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/883
We want extended keys to have the same size as their parent key,
but this is currently broken and the keys end up with their
parent key's preferred size (which is smaller than its allocated
size).
This is due to the way ClutterActor's width/height properties work,
which only return the "real" (i.e. allocated) size when the allocation
is valid, and fall back to the preferred size otherwise.
As changing an StWidget's hover state involves adding or removing
the `:hover` pseudo class, this is currently always the case.
Creating the extended keys first means the keyButton's allocation
is probably valid, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1976
Mutter and Clutter was changed to pass around the current target
framebuffer via the paint context instead of via the deprecated Cogl
framebuffer stack.
The framebuffer stack has also been removed from Cogl so change to use
the one in the paint context instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
While still leaving them unused, pass around ClutterPaintContext and
ClutterPickContext when painting and picking.
The reason for splitting this change up in two is to make it possible to
bisect easier in between the API change and the change to using the
framebuffer passed around with the temporary contexts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
When commit c6cea277e replaced Shell.GenericContainer, the check
whether the required width exceeds the avilable width was changed
from using the minimum widths of items to the natural width of the
scroll view.
That doesn't work correctly, as the *natural* width may well exceed
the actually used width: SwitcherList bases its width request on
children's minimum sizes to force labels to ellipsize.
Fix this by using the minimum width of the scroll view's child instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1834
It is true that delete is a javascript keyword, but that doesn't
prevent it from being used as method name - there are event built-in
types like Map or Set with delete() methods!
So if that hack was ever needed, this hasn't been the case for years
now; just removed the hack now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/862
When the extension system is loaded, create the
gnome-shell-disable-extensions file in the users runtime directory. This
file is automatically removed 60s later. The sole purpose of this file
is to be consumed by the systemd units. If the file exists, the systemd
units will disable extensions when the gnome-shell fails.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/858
Since the notification message close button had no border, or mouse
over effect, there was no way to determine whether the mouse cursor
were over the button.
Improve this by adding a message-close-button class for the close
button, and a styling for its hovered state, based on media control
button styling.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/855
Currently when dragging an icon to the space above or below the appGrid
to switch pages, we do so very quickly without checking when the last
page-switch happened. This makes it hard to move icons to pages which
are not the first or the last one, since the other pages are skipped
very quickly.
To fix this, add a timeout of 1 second that blocks switching pages after
a page-switch using drag overshoot occured.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1693
We currently always switch app pages when a dragged app icon
moves outside the grid boundaries, regardless of any previous
page switches. This makes it too easy to switch multiple pages
accidentally, so add a small threshold that the icon has to
move back towards the grid before allowing another page switch.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1693
There's no need for a `inhibitEventBlocker` interface. Since we connect
to "open-state-changed" of our folders in the AllView anyway, we can
just make the event blocker visible while a folder is opened, and hide
the event blocker during DnD.
This allows keeping the eventBlocker reactive at all times and fixes an
issue where DnD to create a new folder is impossible if no folders are
present because the eventBlocker would not get inhibited.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1652
Emitting ::drag-end after changing the slider value via arrow keys
was a cheap way to make the sound feedback work for keyboard input.
But now that the volume indicator plays the sound on ::value-changed
as well, we can stop doing that - after all, key presses aren't drags.
Besides that, this will make the limiting of feedback to actual volume
changes from the previous commit work for key events as well.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
gnome-settings-daemon doesn't play the volume change sound when
the volume stayed the same (that is, it is already at its maximum
or minimum). This looks like the right thing to do, so copy its
behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
Commit 8d4855f100 accidentally removed the volume change feedback
for scroll events. Add it back to be consistent again with moving
the slider via arrow keys, slider drags/clicks and gsd's media keys
handling.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
While those should be concise enough to fit, they may not where
temperatures drop into double-digit negatives. It seems better
to accept some awkward horizontal scrolling in that case than
shorten relevant information.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1926
Commit b779f6f728 added a check to filter out invalid weather forecasts.
However the check is currently done when creating UI for the forecasts,
which means we end up with fewer forecasts than we could display if any
forecasts are invalid.
We can avoid that issue by checking the validity while collecting the
forecasts, so do that instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
We currently always start with the current weather info, then append
forecasts. This is slightly confusing, as the only hint that the
first item is special is the past (and potentially "odd") time.
Stop doing that and base all items on forecasts.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
As we get closer to midnight, we show fewer forecasts than we could
fit, or none at all. It makes more sense to continue the forecasts
into the wee hours in that case, so only exclude past forecasts,
but not ones from following days.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
Weather stations can have unwieldy long names, which don't fit the
limited space we have available. City names are usually more suitable,
so use the name of the nearest city instead if possible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
In case of a very long location name, the label may take up all
available space. Make sure there is at least some spacing between
header and location in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
The two labels use different font sizes, so they don't align properly.
Unfortunately we don't have BASELINE alignment in Clutter, but at least
END comes closer than the default FILL.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
Commit c899453800 lifted the requirement of switcher keybindings
to contain a modifier, however it is currently only possible to
finish it by letting it time out.
Improve that by also accepting space/enter key presses to confirm the
selection immediately.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1883
The noModsTimeout obviously finishes inside a timeout callback, which
means `global.get_current_time()` might return Clutter.CURRENT_TIME (ie.
0) when called inside it, because it's not called while handling an
event. This means when switching apps or activating a window, the
timestamp passed to `activate_window` may be 0, which is the reason why
the altTab switcher is currently broken when using modifier-less
keybindings.
Fix that by using `meta_display_get_current_time_roundtrip`, which
always return a valid timestamp, instead of
`shell_global_get_current_time`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/847
Remove setCurrentPage() function, introduce setCurrentPosition() instead,
which allows to have fractional positions.
Make inactive dots smaller, filled and partially transparent, as opposed to
larger and fully opaque active dot. Make dots smaller overall, remove
borders. Interpolate each dot between active and inactive state based on
scroll position.
Make it impossible to "uncheck" the active dot.
Thanks Florian Müllner for parts of the code.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1932https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/843
We slightly delay showing the switcher popup to avoid flashing it
briefly in the common case of quickly switching back-and-forth
between two windows.
However some users perceive this delay as slowness. Address this by
showing the popup immediately when another key press is consumed
(that is, a key like Tab is pressed).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1928
Since the mpris implementation of the notification tray supports showing
multiple notification (one for each player), it doesn't make sense to
have only one global property to store the message, since that only
allows referencing one message at a time.
Instead, handle the MediaMessages completely inside the scope of
`_addPlayer()`, this should allow showing more than one message again,
which broke with commit 4dc44304df [1].
[1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/791https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/833
Because the message actor could also be undefined or a already
deallocated ClutterActor, we sometimes fail to show the error message
and get an error from Gjs instead.
So make sure we always log the proper error message and just leave out
the actor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/833
It may happen that the app icon is destroyed with a drag
monitor still around, in which case, a load of warnings
will be shown.
Make sure to remove any pending drag monitor on destroy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
When removing the last icon of a folder, FolderView first removes
the folder from org.gnome.desktop.app-folders.folder-children, then
proceeds to reset all its keys, which removes the relocatable schema.
That order of operations turns out to be problematic. Removing the
folder from 'folder-children' destroys the folder icon, which in turn
destroys the folder view, which throws a load of warnings in the
journal.
Fix that by removing the folder after resetting the schema keys. In
fact, what we're doing here is not using 'this' anymore.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
The variable that holds the list of application icons is
called 'newApps', but that technically was never true,
since we only create new app icons when necessary.
Rename it to 'appIcons'.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
The views (AllView and FrequentView) build a list of all applications
they contain. BaseView then diffs between what's currently added, and
what needs to be added, and removed.
This approach has a problem though: creating an AppIcon or a FolderIcon
connects to various signals, and we confuse the garbage collector.
When building the list of applications, instead of always creating new
icons, try to use already existing icons first.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1610
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1694
GWeather.Info.get_value_update() may indicate that the forecast is not
valid, or it may return a timestamp of 0 to indicate the information has
never been updated. In both of these cases, skip creating a widget for
it, as the information will not be accurate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/835
If the clock is set to 12h, the AM/PM in the weather forecast times
should be clear from the context, because they are the immediately
following hours. This makes it less likely that the times will be
ellipsized (in which case the AM/PM wouldn't be shown anyway.)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/835
While we support a reasonable list of layouts nowadays, we don't
include many variants like `fr+oss`. Instead of directly falling
back to the `us` layout, try stripping the variant first, as the
base layout is likely closer to the expectation than `us`.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1907
When cancelling the PolkitAgent session before disconnecting the signal
handlers, we receive a "completed" signal where `gained_authorization`
is set to FALSE, which means we show an error message inside
`_onSessionCompleted()`.
This in turn means we show an error message every time we cancel a
session. In practice this wasn't really relevant so far since we only
destroyed the session when an actual error occurred before. Now that the
dialog supports empty passwords, we also call `_destroySession()` when
the user changes and no longer has a password set, and in this case we
want to cancel the current session without showing an error message.
So to fix this, disconnect the signal handlers before cancelling the
session, which makes sure we don't receive the last "completed" signal
in case we cancelled the session ourselves. This change also allows
removing `this._wasDismissed`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/829
When a user has no password and a polkit authentication is started,
instead of blindly initiating the admin session, show the regular
"Authentication Requested" dialog (but without the password entry). This
makes sure that the user's admin session is only effectively started
after the user chooses to proceed with the authentication, which
provides an extra confirmation step that can be vital for critical
tasks.
To do this, we show the dialog inside `_onUserChanged()` right after the
dialog was created instead of calling `performAuthentication()` from
`_onInitiate()`. The bug mentioned in `_onInitiate()` is no longer an
issue since we show the dialog in all cases now anyway.
Ideally we should use a different wording than "authentication" when the
user has no password set, and use "confirmation" instead. However polkit
already sends the requests with such messages (e.g. "Authentication is
required to configure software repositories"), and it's important to
show those to the user, so this patch keeps the regular wording.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/829
Since `_destroySession()` is not only called before we try to initiate a
new authentication session with Polkit, but also when the dialog is
closed, it's currently possible that key focus is grabbed by the close
button after the dialog was dismissed and hidden. This is causing a bug
where after dismissing one of multiple queued dialogs, key focus goes
away and keyboard navigation with the new dialog is impossible.
Fix this by only resetting the UI of the dialog if the dialog is still
opened/visible at that point.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/828
