We currently create the default folder with the corresponding
app list, regardless of whether the apps are actually part of
the default install or not.
This matters when a user explicitly install such an app later,
as it will be hidden away in the folder rather than appended
to the app grid as expected.
To avoid that, only add currently-installed apps to the folder
when creating it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
Defining default apps as serialized GVariants isn't very human-friendly,
which likely contributes to the fact that the lists are in parts horribly
outdated (Books! Cheese! Screenshot! gedit!).
Instead, generate the lists at build time from simple text files, which
should be much easier to update.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
When there are 3 or more windows in WorkspaceLayout, showing or hiding
window preview overlay in some certain orders could cause
inconsistencies in windows' vertical arrangement.
Let's take window A, B, C as an example. Initially, A is above B and B
is above C in workspace layout like this: A -> B -> C.
After opening activities, user could:
1. Move cursor to B preview, which would move B above all in layout:
B -> A -> C
2. Move cursor from B to C preview. When C's showOverlay() is called
before B's hideOverlay(), _restack() would move C above all and don't
change B's arrangement:
C -> B -> A
3. Finally, move cursor away from C's preview:
B -> A -> C
In this case, when user closes Activities, they would see window
stacking wrong for a while.
This commit adds some extra logic in _restack, checking the
_stackAbove's _stackAbove when this._stackAbove._overlayShown is true.
Though it's still not guaranteed to be always consistent as there could
be several WindowPreview with _overlayShown as true if pointer moves
really fast, this helps avoid glitches in many cases.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4638.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3460>
The new design requires that other messages and groups are faded when the user
has a group expanded. This introduces a new GLSL shader to provide the
desired effect. The new shader is used for the already existing scroll
fade and the previous one is removed. The two fades need to work together to
ensure that resulting fade looks good.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
We need to track message order separate from the widget children order,
because of how notification groups will add a cover over other messages
when a notification group is expanded that will prevent interaction with
any message other then the expanded notification group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message grouping by source we need more control over the list of
messages to reflect this change rename the MessageSection to
MessageView. Message from different sources will be added to the
MessageView directly in a future commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message/notification grouping by source we need more control over
each single message therefore in a future commit the
MessageListSection will contain all messages directly instead of having
a separate section for different source (notifications and media).
The lost NotificationSection and MediaSection will be readded in a
future commit as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
Section visibility has become less complex when moving events
out of the message list. We no longer need different behavior
in different sections, so we can instead control the visibility
of the entire list in a single place.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
The `Notification` object is destroyed before the `Message` widget so
during the removal animation the user still could click on the `Message`
and activate the notification. This ensures we don't warn about it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
And change the `close` signal on `Message` to run the default handler
last, which allows other signal handers to stop the signal emission
chain.
This change shouldn't have much effect on existing code but will be
needed for by-source notification grouping.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
Since we have now the `notification-removed` signal on
`MessageTray.Source` we can use it instead of connecting to the
`destroy()` signal for each single notification in the
`MessageListSection`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
The widgets `NotificationMessage` and `NotificationSection` in `calendar.js`
aren't used only by the calendar.
Move the two widget to messageList.js since once we add by-source grouping for
messages (which will happen in a future commit) we need a much tighter
coupling between them and the rest of the MessageList. In future the
`NotificationSection` will need to be removed to make expanding of
groups work.
This also removes a circular import of files: `calender.js` imports
`messageTray.js` and it imports `calender.js`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
Since commit eeddf49371, the menu button in toggles is separated
by an actual widget rather than just CSS borders.
However the menu button can be hidden, in which case the menu toggle
acts as a regular quick toggle. The separator shouldn't be visible
either in that case, so hide it.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8159
Fixes: eeddf49371 ("style: Improve the styles for the separation in quick setting buttons")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3621>
There are two instances where we set the deprecated `vertical`
property with a `{vertical}` shorthand that escaped previous
greps; move those to the new `orientation` property too.
Fixes: b75b4abaf0 ("js: Set BoxLayout orientation")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3618>
Since `Spinner` is no longer a subclass of `Animation`/`AnimatedIcon`,
the latter are now unused. Apparently that's not only true for
gnome-shell itself, but also extensions, so there's little reason
for keeping the former base classes around.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3612>
The container is tightly coupled with the preview, and there is
never a need to replace it at a later point. Set it directly
during construction, so the underlying base class can make
this explicit by marking the property as construct-only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
This adds a comment to make clear that the Utilities category is
intended to be organized alphabetically by the display name of
the apps (*not* by the desktop file names), and adds comments
with the current display name of each app.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3609>
These have (Logs) or previously had (Characters) the
X-GNOME-Utilities category in their .desktop file and so showed
up in the Utilities folder (despite 152faae claiming that the
category was "completely unused"). Characters had the category
removed in
https://gitlab.gnome.org/GNOME/gnome-characters/-/commit/210eb09
in apparent expectation that it would be added to the list, but
it seems it was not.
We could restore consideration of the category, but I guess let's
just list the apps instead? I don't know if any others are
missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3607>
To prevent sporadic shutdown failures:
```
** Message: 17:08:37.707: Shutting down GNOME Shell
(gnome-shell:91892): Gjs-CRITICAL **: 17:08:37.728: Object .Gjs_ui_panel_Panel (0x5b53524fb030), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3601>
This implements wellbeing screen time limits in gnome-shell. It depends
on a few changes in other modules:
- New settings schemas in gsettings-desktop-schemas
- A settings UI in gnome-control-center
- User documentation in gnome-user-docs
It implements the design from
https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/wellbeing/wellbeing.png.
The core of the implementation is `TimeLimitsManager`, which is a state
machine which uses the user’s session state from logind to track how long
the user has been in an active session, in aggregate, during the day. If
this total exceeds their limit for the day, the state machine changes
state.
The user’s session activity history (basically, when they logged in and
out for the past 14 weeks) is kept in a state file in their home
directory. This is used by gnome-shell to count usage across reboots in
a single day, and in the future it will also be used to provide usage
history in gnome-control-center, so the user can visualise their
historic computer usage at a high level, for the past several weeks.
The `TimeLimitsDispatcher` is based on top of this, and controls showing
notifications and screen fades to make the user aware of whether they’ve
used the computer for too long today, as per their preferences.
Unit tests are included to check that `TimeLimitsManager` works, in
particular with its loading and storing of the history file. The unit
tests provide mock implementations of basic GLib clock functions, the
logind D-Bus proxy and `Gio.Settings` in order to test the state machine in
faster-than-real-time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/130
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
- remove the highlighting js in favour of color definitions, to fix it not really working in light theme or high contrast
- add a bunch of color definitions to set the color of the menu button in the different styles
- drop the border drawing for a separator, to fix visual issues with the high border radius, in favour of a separator element
- change the class names of some things to make it understandable
- bit of overall css tidying
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3554>
- renamed all assets to start with osk- disambiguate them from other keyboard status icons
- updated the design of hide, enter and keyboard layout icons to be more rounded
- new symbolic assets for emoji and delete actions to move away from using 16x16
- updated keyboard scss to use the scalable icon definition
- updated the zwnj asset to align with GNOME icon style
- changed all references to icons in layouts
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3555>
When the 'text-scaling-factor' key changes and it's set bigger than 1.0,
the corresponding switch is activated in the a11y menu. However, since
commit 946ee936926a0e14fa5f86f62da757bcb581a147, setting the state using
`setToggleState()` also fires the 'toggled' signal, which is I think
correct and intended.
However, that means the GSettings handler for 'text-scaling-factor'
should block that 'toggled' handler when it sets the switch active, as
otherwise the 'text-scaling-factor' is always set to 1.25 when it is
first made bigger than 1.0.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3574>
