Variable names like "sourceNotificationStackDoneShowing" are too
long, and too undescriptive: this one points to a source, not a
notification stack that has been done showing.
As the close button of folder popups overlaps at the top, it ends
up being cut off if the folder is located at the very top of the
view. Fix this glitch by taking the button's overlap into account
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
We already take care of growing the view if open folders overlap
at the bottom, however folder popups may still end up being cut
off when opening above the source icon - if the popup is high enough,
its y coordinate will be negative and therefore outside the parent's
allocation. To fix, we can either make sure that folders pop up below
their source icon in that case, or adjust the parent grid's position
as necessary while a folder is open. This implements the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
If the view doesn't fill the available space, content should still
start at the top rather than the center - not least the positioning
code for folder popups assumes that, so set the appropriate expand
flags.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
The main overview actor was made reactive to catch scroll-events
and propagate them; after some code shuffling, the actor that
catches scroll events ended up not being the same actor that's
supposed to propagate this, which broke using the scroll wheel
to switch workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=700595
Currently we show the workspace popup for relative targets ("up", "down"),
but not when targetting a specific workspace directly.
There is not really a good reason for that difference, and as we are about
to introduce a new shortcut to target the last workspace (which does vary
with dynamic workspaces), it makes sense to unify the behavior and always
show the switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=659288
Currently we stop monitoring application usage when disabling the
'enable-app-monitoring' setting, but we still expose previously
gathered data in the app picker's frequent view. This is not what
users should expect, so hide the view in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=699714
Some keyboard spot a dedicated search key, which gnome-settings-daemon
currently handles by spawning gnome-search-tool. It makes a lot of
sense to promote the Shell's integrated search feature instead, so
expose an appropriate DBus method g-s-d can use.
https://bugzilla.gnome.org/show_bug.cgi?id=700536
This is technically a smidge slower due to the constant bisect insert,
but since this should only happen when we make a Wi-Fi dialog, it's
insignificant.
https://bugzilla.gnome.org/show_bug.cgi?id=700322
Commit 2499f2ed80 went back to using shell_app_activate() for
selecting an app, which favors windows on the current workspace;
this is the behavior we want for instance when activating a
launcher, but it's wrong for the alt-tab list - explicitly
request the first (e.g. MRU) window in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=700356
Since commit c84dc6254d, popup menus are closed automatically
when another menu opens (to catch the case where a menu is opened
by keyboard shortcut, which wasn't handled before). However in the
case of child menus, both child and parent are expected to be visible,
so handle this case explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=699678
Wrap new GtkMenuTracker API that adds an easy way to bind to
tracker items, and use it to add back support for submenus.
This also adds support for a submenu feature that we didn't
have support for before, action namespaces.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
This pulls in new upstream API that Ryan will maintain, removing
code on our side.
Currently, our implementation of submenus will be gone, but this
will be fixed in a few commits.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
When opening an application folder, it should take key focus to
allow for keynav; also, Escape closing both folder and app picker
is unexpected, it should only close the popup.
https://bugzilla.gnome.org/show_bug.cgi?id=695314
The point of a hash table is that you don't need to list all the
elements. To avoid that, keep a "clearableCount" in MessageTray,
which can be used by the message tray menu to show and hide the
clear item, and that is updated in constant time when sources
are added or removed.
https://bugzilla.gnome.org/show_bug.cgi?id=700194
Upon popMode, MessageTray will try readding all notifications
to their rightful parent, so we must tell NotificationBox to
relinquish them before st_bin_set_child() fails (leaving a dangling
child pointer and crashing at the next allocation)
https://bugzilla.gnome.org/show_bug.cgi?id=698812
Like screenshots, the screen recorder can be a useful tool in other cases
than being triggered by a keyboard shortcut. To account for that, export
a Screencast DBus API similar to the existing Screenshot interface.
https://bugzilla.gnome.org/show_bug.cgi?id=696247
Our built-in screen recorder is implemented as a component, so it will
just be disabled when the session mode doesn't allow screencasting.
However we will expose screencasting functionality on DBus as well, and
while it makes sense to restrict its availablity to the same modes as
the existing recorder, exporting/unexporting the service depending on
the session mode is not very consumer friendly.
For that reason, add an additional 'allowScreencast' property that for now
mirrors the availability of the 'recorder' component.
https://bugzilla.gnome.org/show_bug.cgi?id=696247
There is not always a clear distinction between code and style,
which is why the interface ends up being mostly unusable when we
end up without *any* style, for instance because the specified
application-stylesheet is corrupt.
Setting the default stylesheet in addition to the application-stylesheet
is no guarantee for non-default themes not messing up the interface, but
it should at least lower the risk ...
https://bugzilla.gnome.org/show_bug.cgi?id=700097
Metacity's Ctrl+Alt+Tab would include X11 windows
with hints like GDK_WINDOW_TYPE_HINT_DOCK and
GDK_WINDOW_TYPE_HINT_DESKTOP (there are more conditions, but that's a
good start). If we're in normal mode, those are visible and it's OK
to display those in the Ctrl+Alt+Tab order, but if we're in the lock
screen or the unlock dialog, they're not visible and it doesn't make
sense to focus them.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=699862
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Florian Müllner <fmuellner@gnome.org>
