And adapt existing callers to the new API. This will allow us to
implement a way to launch applications on the discrete GPU for systems
where an "Optimus" system exists.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
If Bluetooth is on but there aren't connected devices, the status in the
menu reads "Not in Use". This is potentially confusing: it's a negative
statement, even though Bluetooth is on. It also sits uneasily (and looks
even more confusing) next to the submenu item "Turn Off".
Changing the string to "On" is better.
https://bugzilla.gnome.org/show_bug.cgi?id=756432
This allows us to pass metadata fields besides the message
to log. So, if the log() call is made from an extension,
pass the extension name and UUID to the logger.
This is useful for extension developers to debug their code
as well as to instruct their users to send debug info to them
by running something like this:
journalctl GNOME_SHELL_EXTENSION_UUID=<extension@uuid>
https://bugzilla.gnome.org/show_bug.cgi?id=770717
NM upstream would like to reduce periodic scanning, and that means
that clients should request scans themselves while their WiFi list
is open. Similar to the Windows and macOS WiFi dialogs/lists.
https://bugzilla.gnome.org/show_bug.cgi?id=767918
We currently rely on the "monitors-changed" signal of LayoutManager to
relayout the OSD window. That is not enough, since the scale factor also
changes the way the OSD window is sized, and that can be updated after
"monitors-changed" has been received.
The visual effect is that under some circumstances, the OSD window will
have the wrong size under HiDpi.
This commit fixes the issue by triggering another relayout when the
scale factor changes.
https://bugzilla.gnome.org/show_bug.cgi?id=772723
Similar to bug 667552 for the app switcher, attached modal dialogs
can result in an unexpected window order in the window switcher:
Selecting a window with an attached dialog will focus the dialog
instead, but as the dialog itself is ignored in the window list,
its last-used timestamp is not taken into account for the position
in the MRU list. Fix this by fetching the list of all NORMAL windows
and filter out skip-taskbar windows ourselves, while making sure that
windows appear in the position of their attached modal dialog where
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=747153
We only connect to the corresponding property notifications after both
Client and RemoteSettings are ready, so we may miss the initial signal
emission. Make sure to pick up the connections in this case to fix the
network indicator not showing up.
https://bugzilla.gnome.org/show_bug.cgi?id=772249
Similar to windows on another workspace, selecting a minimized window
doesn't look quite right - the selected window disappears, then animates
back in. Fix this by adding support for skipping the next effect to the
wm and use it to bypass the unminimize animation.
https://bugzilla.gnome.org/show_bug.cgi?id=771536
Both 'cycle-group' and 'cycle-window' shortcuts allow cycling through
windows on all workspaces. While this works, it looks quite broken
since we started showing clones for highlighting: the selected window
vanishes (when its clone is destroyed), then slides back in with its
workspace. Instead, slide the selected window to its workspace like
we do for the 'move-to-workspace-*' shortcuts.
https://bugzilla.gnome.org/show_bug.cgi?id=771536
Commit 3171819c improved window cycling by using a dedicated to clone
for highlighting rather than activating all cycled windows. Original
window actors are hidden while its clone is showing, and shown again
afterwards, however the latter is wrong for actors that are not supposed
to be visible (for example where the window is minimized, or on a different
workspace). Fix this by properly syncing the actor's visibility instead
of showing it unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=771536
Since commit 82950ecea, we acknowledge pending messages when closing a
chat notification for a channel we are handling to prevent the channel
from popping up again immediately. While this isn't an issue for channels
we don't handle, the unread messages of the destroyed notification are
still considered for the messages indicator in the top bar, which is
clearly confusing (in particular when we end up showing the indicator
without any notifications in the list). As it's arguably correct to not
meddle with a channel handled by someone else, just reset the cache of
pending messages to address this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=770888
Mutter's plugin destroy event doesn't happen if a window is hidden
when it gets unmanaged so we also need to handle the
MetaWindow::unmanaged signal to check whether the parent should
dimmed.
https://bugzilla.gnome.org/show_bug.cgi?id=752524
meta_window_foreach_transient() iterates through all transients of a
window, not only direct transients. This means that simply checking if
a transient is an attached dialog isn't enough because it might be a
non-direct transient for the window we're checking, in which case we
don't want to dim the window.
In particular this fixes windows not getting undimmed when they have
more that one level of transient children and the direct transient gets
destroyed. In that case we would still find at least one non-direct
transient child and decide to keep the window dimmed.
https://bugzilla.gnome.org/show_bug.cgi?id=770163
Commit bd6e7f14d1 reimplemented the cycle keybindings to
fix cycling between more than two windows, but the approach
of highlighting cycled windows by actually focusing them has
the drawback that cycling messes up the MRU order of windows.
To fix this, only change the window focus when the operation
finishes, and use a dedicated actor that draws a border around
a window clone for highlighting.
https://bugzilla.gnome.org/show_bug.cgi?id=771063
There's no particular reason for this actor to be reactive and thus
preventing input events to reach actors underneath, e.g. quickly
clicking on something while the popup isn't yet finished animating
out.
https://bugzilla.gnome.org/show_bug.cgi?id=770382
Have it notify properly of changes to the current input source, as
well as exposing those in get_groups().
The support for virtual keyboard events has been replaced by
ClutterVirtualInputDevice, which can be thought of as the equivalent
to the XTEST devices in X11.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
If a sandboxed app requests access to some system resource (camera,
microphone, location), the portal frontend needs to ask the user
for permission. In GNOME, we want this to be a system modal dialog,
so provide an org.freedesktop.impl.portal.access implementation
that exposes a generic system modal permission dialog on the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=768669
We currently use the :active pseudo class to mark the selected day
in the calendar. Whenever the selected date changes, the class is
added to the corresponding button and removed from all others.
However when the selected date doesn't change (i.e. when clicking
the already selected date), the buttons are not updated and the
use of the :active class conflicts with StButton's builtin handling
of the class - the class is removed on the button up event and the
button is deselected.
Fix this by simply using a different pseudo class.
https://bugzilla.gnome.org/show_bug.cgi?id=746867
The last patch fixed marking days in the calendar where all
events are ignored, but it doesn't pick up the change when
an event is hidden. Emit an appropriate change notification
to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=768538
Ignoring events is currently implemented in the message list's
event section, which means that the calendar does not consider
ignored events when marking days with events. In order to fix
this, move the handling of ignored events to the event source,
which is shared between both components.
https://bugzilla.gnome.org/show_bug.cgi?id=768538
Commit 9b07ce1d0d broke the code that keeps the OSD window square.
Use that opportunity to move away from the hack of setting the
min-height style property from code and adjusting the width on
allocate, and implement a proper constraint instead.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
ClutterActor:width is a floating point property, so it will not be
automatically rounded to non-fractional values that properly align
to pixels. To fix the resulting blurriness, add explicit rounding.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
Commit 9b07ce1d0d changed the OSD window's level bar to be a regular
actor instead of a custom drawn bar. The bar actor's width depends on
both the configured level (e.g. 40%) and the available width, however
the width is currently only updated when the configured level changes.
Fix that by properly considering changes to the parent's width as well.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
Commit c39ffa111 moved the signal handling from the controls- to the
background-group to enable scrolling on non-primary monitors.
However this broke scrolling on reactive overview elements as the
workspace switcher, as they're not descendants of the background.
To fix, move scroll-event handling to the overview group itself,
which is the common ancestor of all overview elements.
https://bugzilla.gnome.org/show_bug.cgi?id=768316
When we restart, we need to update the struts for the screen before
we enter the main loop, or maximized windows will get resized to the
size of the screen without struts, then resized back.
A workaround is needed for a Clutter bug that occurs when we get
the size of an actor before the first paint of the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=761566
The memory which MetaBackground resides is freed automatically, when its
wrapper object Background is freed by garbage collection. But because the
memory for MetaBackground is huge, changing the background or changing the
background mode repeatedly makes a lot of memory to be in use until garbage
collection runs.
This patch frees the MetaBackground object explicitly when its
MetaBackgroundActor is destroyed which is the moment that the memory in the
object is not used anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=766353
Signed-off-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
This isn't a performance critical actor and the NVIDIA driver discards
offscreen buffers in some cases which would require us to go through
extra hoops to handle here which isn't worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
It is odd to switch workspaces on the primary monitor when panning on
a monitor without workspaces, so reject the gesture on non-primary
monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
It is odd to switch workspaces using the scroll wheel when the pointer
is on a monitor without workspaces, so only handle scroll events on
non-primary monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
We allow activating a workspace by clicking it when we know that
the user did not try to select a window and missed (namely: the
workspace is empty). However we currently always check for an
empty workspace on the primary monitor, which doesn't make sense
when the click happened on a different monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
Both the Overview::scroll-event and actions added via addAction()
are meant to work anywhere in the overview, but for now only work
on the primary monitor. Move the handling to the background group
that is known to span all outputs to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
The stack was used to overlay a message indicator over the overview
group. That indicator is long gone, so there's no longer a need for
an intermediate actor in the hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
Initializing the upper bound to zero means that on panning we'd start
scrolling from the first workspace even if the current workspace when
entering the overview was different since StAdjustment clamps the
value to be inside bounds.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
