Commit 64b2b4a7d4 changed the monitor layout handling, resulting
in some layout errors due to a subtle change in memory handling:
when zooming a window in the overview, the available zoom area is
calculated by subtracting the panel height from the primary monitor
area. This area used to be a copy of the monitor rect, but as now
the rect itself is returned, zooming a window on the primary monitor
repeatedly modifies the monitor rect, leading to layout errors in
various parts of the shell.
Fix by using a copy when calculating the available zoom area.
https://bugzilla.gnome.org/show_bug.cgi?id=654105
Use a longer fade-in time, but with an inout transition, so that the
dialog starts fading in very slowly and then picks up speed after
150ms or so. That way if the user releases Alt+Tab right away, they'll
never actually see the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=652346
Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=636963
This is better for memory management, and we'll see any errors this
way, which we may eventually want to do something with.
We need to make this change because gjs recently started checking
(allow-none) on callbacks.
Every place that called chrome.addActor was specifying
visibleInOverview:true, and no existing designs call for chrome that
disappears when you enter the overview, so just drop that as an
option.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
Due to lockdown settings or Polkit policy, shutdown may not be
available. If this is the case, the "Power off ..." action should
be hidden from the user status menu.
https://bugzilla.gnome.org/show_bug.cgi?id=652038
Sliding out the workspaces pager when starting a drag causes a lot
of motion. With the pager only hiding if workspaces are not used,
it is better to require to explicitly hover the workspaces sidebar
for the sliding.
https://bugzilla.gnome.org/show_bug.cgi?id=652730
Use the new PopupSwitchMenuItem functionality when bluetooth cannot
be enabled. Use it also for showing "connecting..." when activating
device items.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
Moves and converts NMDeviceTitleMenuItem from network.js into
PopupSwitchMenuItem, so that it can show both a switch and a
greyed-out status label. This will be soon used by the Bluetooth menu.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
_createNetworkItem was always appending access point at the end of
the menu when their position was < 5 (NUM_VISIBLE_NETWORKS), ignoring
the presence or absence of _overflowItem, which thus ended in the
middle of the network list. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=652313
After completing the overview transition, the workspace view is
clipped to avoid overlapping the search entry/view selector titles
while switching workspaces. For clipping, the view's position and
size was used, which works well assuming that the workspace pager
will start hidden or stay zoomed out while the overview is visible.
However, that assumption holds no longer true, as auto-hiding the
pager now depends on the number of workspaces, and thus may change
while in the overview. For instance, when starting with the pager
being visible, the clip area ends up being too small when moving
all windows to the first workspace (and thus triggering auto-hide).
As a fix, handle the clip rectangle separately from the view's
geometry, and set it always to the area the workspaces would
occupy with the pager hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=653142
We call global.sync_pointer() on MetaScreen::restack as a hack to try
to fix up the hover state after a pointer grab. Previously we were
doing this in chrome.js, since there was already a ::restack handler
there anyway, but this isn't really related to the chrome at all, so
move it to main.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
This is better for memory management, and we'll see any errors this
way, which we may eventually want to do something with.
We need to make this change because gjs recently started checking
(allow-none) on callbacks.
Workspace thumbnails are supposed to be miniatures of the "real"
workspace they represent, but currently they show minimized windows
like the window picker.
Instead, hide minimized windows and track changes to update the
thumbnail accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=651569
With commit 59a3e393f9 whether the workspace pager should autohide
now depends on the number of workspaces. As we only track changes
to the number of workspaces while the overview is visible, we miss
changes in "normal mode", i.e. when creating a new workspace by
moving a window with ctrl-alt-shift-arrow; as a result, the pager's
autohiding might be incorrect when entering the overview after that.
As a fix, keep tracking changes to the workspaces when the overview
is hidden and update the zoom options.
https://bugzilla.gnome.org/show_bug.cgi?id=653078
Commit 429f809b7 fixed an exception in getDragActorSource(), but
the returned actor is only an approximation (e.g. in contrast to
the actual drag actor, it includes the label).
Try a bit harder to return the correct actor and only fall back to
the approximation when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=645990
The purpose of autohiding the workspace pager on the right was to
avoid exposure of workspaces to users who are not using them.
However, for users who do use workspaces, the behavior limits the
purpose of the overview. To fix, always show the pager if more than
one workspace is actively used.
https://bugzilla.gnome.org/show_bug.cgi?id=652714
Using the list of stylesheets loaded with st_theme_load_stylesheet(),
one can build an StTheme that is completely identical to the previous
one, except for one property (application-stylesheet).
This allows rt and the user-theme extension to work while respecting
the theming of other extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=650971
Currently the user has to find an empty spot in the workspace
to be able to launcha new instance of an app using dnd.
This is unnecessary hard, so just allow dropping on windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=652079
The screen panel in System Settings has a preference whether the
screen should be locked on suspend. This works fine when suspending
by closing the lid, but the "Suspend" menu item in the user status
menu ignores the setting and always locks the screen.
Fix by activating the screen saver before suspending rather than
locking explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=652327
As the Shell does more than observing channels (users can interact with them),
it has to be an Handler as well. We have to make sure that all the new
incoming text channels are handled by the Shell by default, so we make it an
Approver as well.
From an user point of view, the only difference is that Empathy's tray icon
will stop blicking when receiving new channels.
We rely on ChannelDispatcher.DelegateChannels() and PresentChannel() to
interact with Empathy. Those methods have been implemented in
telepathy-mission-control 5.9.0 and telepathy-glib 0.15.0.
If we have more than 5 (which can happen with VPN connections), place
them into a More... submenu, which also becomes scrollable if needed.
To protect from race conditions and ordering issues while reading
connections, sort them in alphabetic order when the timestamp is equal.
https://bugzilla.gnome.org/show_bug.cgi?id=651602
shell_global_get_memory_info() is a new function which extracts a few
global counters we have already, namely glibc's mallinfo, spidermonkey's
JSGC_BYTES, and gjs' counters for boxed/object/etc wrappers.
There is some slight overlap with perf; ultimately though I'd
like this function to do some more extensive analysis, so it wouldn't
be quite the same.
perf is going to be mainly concerned with how big the whole process
over time is; memory_info is for debugging memory leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=650692
