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>
Using the user object at `/org/freedesktop/login1/User/self` is
convenient, but has the caveat that login1 does not emit the
`PropertiesChanged` signal for the object.
That is indeed logical, as for signal emissions there is no
sender that can be used to resolve `self`.
The new TimeLimitsManager depends on change notifications for
user properties, so stop using the `self` shorthand and instead
create the User proxy for the user's UID.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
Most of the function is already asynchronous, except for the
initialization of the returned proxy. gjs' D-Bus wrapper gained
some convenience API a while ago that makes this trivial enough,
so use it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
Traditionally, getter/setter functions have been considered a
C convenience, and we therefore didn't bother to add them for
many properties that are only consumed from JS.
However now that gjs optimizes property accesses by calling the
appropriate getter/setter instead, it makes sense to add them.
Leave out ScrollView's [vh]scrollbar-policy properties, as they
have a combined `set_policy()` setter that is consistent with
GTK's ScrolledWindow.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
Some properties have getters and setters that don't follow the
usual naming scheme, and they are therefore not recognized
automatically. Annotate the properties so that g-ir-scanner
picks up the methods.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
Traditionally, getter/setter functions have been considered a
C convenience, and we therefore didn't bother to add them for
many properties that are only consumed from JS.
However now that gjs optimizes property accesses by calling the
appropriate getter/setter instead, it makes sense to add them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
gjs now optimizes property accesses if possible, by calling the
corresponding getter/setter method. For this to work, the method
not only has to exist (obviously), but also match the type of
the corresponding property.
Both `Label` and `Entry` currently define their `clutter-text`
property as `Clutter.Text`, while the corresponding getter
returns the more generic `Clutter.Actor`.
Fix that so that both property and getter use the more specific type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
gjs now optimizes property accesses if possible, by calling the
corresponding getter/setter method. For this to work, the method
not only has to exist (obviously), but also match the type of
the corresponding property.
For some reason the `Global.stage` property is defined as
`Clutter.Actor` instead of `Clutter.Stage`, which is returned
by the getter.
Fix that so that both property and getter use the more specific type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
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>
Support the new `banner-message-path` and `banner-message-source`
settings, which allows loading the banner message from a path
instead of GSettings. This is mainly useful for `/etc/motd` and
similar mechanisms, to show the same message for both graphical
and non-graphical logins.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3558>
Our D-Bus services don't make sense outside a GNOME session, so
they shut down automatically when gnome-shell is not on the bus.
However this does not only apply when activating a service from
a non-GNOME session, but also when restarting gnome-shell on Xorg.
This is particularly problematic for services that shut down
automatically, as they lose all tracking state, even when
re-activated.
Address this by queuing a shutdown check instead of shutting down
immediately, so that the service can pick up the new shell name
provided it appears before the timeout (i.e. two seconds).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7843
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3463>
The service implementation already has to resolve the shell's
unique name to exclude it from sender tracking.
It can just as well take care of watching the shell D-Bus name,
which simplifies the code and will allow for more flexibility
when handling the shell disappearing from the bus.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3463>
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>
