The fullscreen animation code is now generic enough to handle any
size change animations, so stop limiting it to (un)fullscreen to
get animations on (un)maximize as well.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Currently, the translation values are set with the assumption that
one of the actors represents a fullscreen window. In order to
generalize it for any size change transition, we can simply swap
the monitor rect with the source or target rect as appropriate,
and translate the actor from the target to the source position by
subtracting the former and adding the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Since there is already targetRect that represents where the
window is going to move, rename oldRect to sourceRect to
represent from where the window is moving.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
If the popup happens to be mapped beneath the pointer, mutter will now
emit an implicit enter notify event (i.e. not caused by pointer motion).
In this case the switcherPopup still goes and selects the item, which
results in too sensitive alt-tab menus if the pointer happens to be in
the wrong place.
Make highlighting rely on motion events instead, so it always involves
user interaction when triggered by the pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=755164
The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.
https://bugzilla.gnome.org/show_bug.cgi?id=747163
And merge with the "internal" show/hide() ones. Those functions don't
proxy dbus method calls anymore, so it makes no sense to expose these.
Also, the timestamp is no longer needed as there is a single source for
these events.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
The caribou daemon only gives us focus tracking, which is almost 1:1 with
our own FocusCaretTracker implementation. This means we can entirely
replace the Caribou daemon inside gnome-shell, reducing the Caribou
dependency to just libcaribou, and more specifically the
CaribouKeyboardModel we pull the keyboard models from.
As we still need underneath a CaribouDisplayAdapter to drive the keyboard,
reuse the wayland one, which has been renamed to make it look generic, plus
it will use the virtual input device API from mutter/clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
Some search providers such as GNOME Characters want to copy search
results to clipboard. However, on Wayland, clipboards are only
accessible from applications that have a visible surface on display.
This patch allows a search provider to request the shell to copy a
search result to clipboard when 'clipboardText' is included in the meta
of the result.
https://bugzilla.gnome.org/show_bug.cgi?id=775099
We are moving the icon to be added before the text instead of after,
which is consistent with other menu items in other popup menus, such
as the ones in the system indicator's popup menu.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
This allows passing an optional icon parameter to addAction()
so that a PopupImageMenuItem instance is created instead of a
PopupMenuItem if an icon is specified.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
Add an extra check to setIcon() so that either a GIcon or an string
with the icon's name is handlded, so that we can create menu items
in different ways (e.g. by passing a GIcon created from a resource).
https://bugzilla.gnome.org/show_bug.cgi?id=782166
Some extensions out there may fail to reload. When that happens,
we need to catch any exceptions so that we don't leave things in
a broken state that could lead to leaving extensions enabled in
the screen shield.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Recently Music gained a flatpak manifest inside the repo in bug 779905.
However that requires the desktop file to be properly named like
DBUS addresses are.
This patch renames the old Music desktop file to the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=780157
Add a new D-Bus method for setting the monitor labels. This new method
takes connector names instead of output ids for associating with actual
monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Since the workarea and margins are both in pysical pixels dimensions (we
fetch margins from Clutter, not from the theme), but the CSS expects
logical (scaled) pixels, unless we consider the scale factor when
setting max-height, it won't work on a HiDpi display.
This fixes missing scrollbars when the calendar popup is full on HiDpi
displays.
https://bugzilla.gnome.org/show_bug.cgi?id=753305
Generalizing menu toggling via keyboard in commit 1d58ea25ab
fixed keynav in many places, but it turns out that it also adds
unexpected interactions in some cases where the source is not
button-like, as for example the entry context menus provided by
ShellEntry. Commit e33c68a415 fixed one case, however it is still
possible for plain enter/space to unexpectedly trigger the menu
if the entry itself doesn't consume the event, which is the case
when ClutterText:editable is false. However for a general fix, it
makes more sense to consider the source actor's :reactive property
and disable toggling menus via keyboard when they cannot be toggled
by pointer either - expecting non-editable entries to be non-reactive
as well seems like a reasonable assumption, and indeed all our code
follows that pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=758873
It doesn't make sense to tie the proxy code for flatpak's permission
store to the location indicator, just because that was the first
component to use it, so split it into a separate module.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
Setting GWeatherInfo:location to null helpfully doesn't mean
"no location", but "NYC". This obviously isn't what we want
to show users, so track the location validity separately and
consider it when updating the label shown to users.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
When using the 'disable-lock-screen' setting to lock down the screen
lock, the expectation is that users cannot lock the screen. However
as it turns out, all the setting currently does is hiding the lock
button in the system menu and making the lock settings in the privacy
panel inactive. That means that if the 'lock-screen-enabled' setting
isn't disabled and locked down as well, we will just continue to
lock the screen on inactivity - not to mention the keyboard shortcut
that isn't subject to that setting anyway.
Instead of expecting administrators to hunt down every possible way
of locking the screen and disabling it individually, we can easily
handle all cases by refusing to lock the screen when disabled by the
lockdown settings.
https://bugzilla.gnome.org/show_bug.cgi?id=780212
Dragging and dropping app icons is expected to work anywhere over a
workspace, however overlaid elements are added to a separate hierarchy
and can thus block valid drop targets. This wasn't much of an issue
while we had just the window title, but since the addition of the
focus border, drops on window previews stopped working entirely.
Fix this by hiding all non-reactive overlay elements from picks.
https://bugzilla.gnome.org/show_bug.cgi?id=737166
Currently when the wifi selection dialog is open when the screen lock is
activated, the dialog remains visible above the shield. This is clearly
broken, so close the dialog automatically on session mode changes if the
mode doesn't allow settings (as changing the access point is arguably a
user setting).
https://bugzilla.gnome.org/show_bug.cgi?id=780054
The critical hint is meant to be used for notifications that must not
be missed - running out of battery being the prime example - so it
makes sense to ignore the policy in that case and make sure to always
show them to the user. This is consistent with blocking normal
notifications while showing a fullscreen window, but letting critical
ones through.
https://bugzilla.gnome.org/show_bug.cgi?id=779974
Whenever there's more than one pad in the same group (eg. Wacom ExpressKey
Remotes), show a popdown menu to allow configuring those extra pads.
Devices are hot-pluggable, so the popdown menu will update its state
whenever pads are added/removed.
Also, allow to quickly change between pads by switching to its OSD by
just interacting with them. Always given they are in the same group.
https://bugzilla.gnome.org/show_bug.cgi?id=779986
Telepathy's role has been diminishing continuously over the last
couple of years, so while chat integration is a nice feature for
those who use it, it is hard to justify keeping it as a hard
dependency. To address this, split out the component from the
client so we can handle missing typelibs gracefully by not
providing any chat integration.
https://bugzilla.gnome.org/show_bug.cgi?id=779878
For most notifications, banners are suppressed while the monitor
that is used to display banners is in fullscreen. With the old
message tray at the bottom, this used to be the bottom-most monitor,
but nowadays it's always the primary one, so update the corresponding
code to use the correct monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=779819
The telepathy integration was written at a time where gjs didn't
allow to inherit from GObject classes, which is why we needed a
C helper class. This hasn't been the case for a while now, so cut
out the middle man and implement Tp.BaseClient directly.
https://bugzilla.gnome.org/show_bug.cgi?id=771721
Rename the signals which have been used to handle XDnd events to more inclusive
ones. So that these signals can be used to handle the DnD events in Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=765003
Commit c6f22826cf added a call to update() to refresh the notification
time for sent and received messages. However as it omits the bannerMarkup
parameter, escaped text like ''' now makes it through verbatim.
Rather than adding the parameter, we can just refresh the timestamp in
the existing update() call to fix the issue - it means the notification
timestamp is only refreshed for received messages, but that reflects
the text shown in the notification, which isn't updated for sent
messages either.
https://bugzilla.gnome.org/show_bug.cgi?id=779435
Media notifications currently always show the forward and backward
buttons as clickable, regardless of whether the corresponding action
is available or not. Media players usually address this by rendering
controls insensitive in this case, so do the same here.
https://bugzilla.gnome.org/show_bug.cgi?id=773884
Without the boxy background, event messages look a bit plain and
unaligned with other messages. Adding an icon addresses this,
however as repeating the same icon over and over again in case of
many events would be rather noisy, only show it for the top event
as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Update the notification style according to the latest mockups:
- make notification icons smaller and prefer symbolic variants
- remove background box when not hovered/focused
- increase spacing between elements
- use normal text sizes
https://bugzilla.gnome.org/show_bug.cgi?id=775763
For notifications in the message list, it is usually less relevant
when exactly it occurred, but how long ago. So rather than showing
the exact time and expecting the user to figuring out the timespan
themselves, change the format to something human readable.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Currently the secondary actor (if set) and the close button are
exclusive, that is the latter replaces the former on hover. As
the swapping feels rather busy and there's no real reason both
cannot be shown at the same time, keep the secondary actor always
visible.
A welcome side effect is that it no longer needs to be placed at
the end, so we can move the notification timestamp right next to
the corresponding title.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
