If for some reason an extension needs to destroy the AppMenu object,
currently it is not possible to do this cleanly due to these signals
remaining connected.
https://bugzilla.gnome.org/show_bug.cgi?id=698531
We already do this when navigating between menus via mouse or
keynav, but miss cases where a menu is opened by other means,
for instance via a keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=686756
It makes sense to allow closing the app menu with the same shortcut
that is used to open it, so make it a toggle action and allow it
TOPBAR_POPUP mode.
https://bugzilla.gnome.org/show_bug.cgi?id=686756
Currently all keybindings are disabled while some popup menu is open.
However some keybindings may still be useful in some cases, so expose
GrabHelper's modal params parameter to allow specifying a keybinding
mode for particular menus.
https://bugzilla.gnome.org/show_bug.cgi?id=698938
Eval() is expected to return a boolean success value and a string result.
However when the function is disabled (via the development-tools setting),
we return null for the latter which is not a valid string value.
Return an empty string instead.
https://bugzilla.gnome.org/show_bug.cgi?id=698959
In order to use a different spinner image in classic mode (or any
other mode specific style), get it from CSS rather than hardcoding
a particular image.
https://bugzilla.gnome.org/show_bug.cgi?id=693688
Similar to the existing generic getter methods, add lookup functions
for URL properties like the standard background-image/border-image
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=693688
For classic mode, we want to use a different styling for the spinner,
so we will pick up the image filename from CSS to make use of mode
specific styling. As the CSS will give us a full pathname, adapt the
API to take a full pathname instead of building it inside AnimatedIcon
from the passed basename.
https://bugzilla.gnome.org/show_bug.cgi?id=693688
GrabHelper already takes care of putting the key focus back on the
widget that had it when the grab was established.
ShellEntry's close() has recently become harmful since it's now called
from the menu's destroy() method and that is called in the entry's
destroy handler which means that this._entry might no longer be valid
at close() time.
https://bugzilla.gnome.org/show_bug.cgi?id=697560
The actor is the same as the drag actor in this case, but we tend to
set properties on the drag actor and get them from the actor elsewhere
in this codepath. Make this consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=697504
This causes very low performance in some situations (like multiscreen). Proper
fixes are too invasive at this point (3.8.1) so lets just remove the shadow
for now and add it back later once he have fixed it.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
It turns out that we never destroyed modal dialogs when closing
them, causing them to still linger in the scene graph even when
there were no references to them in the JS. The one case where
we don't want to destroy modal dialogs after being closed is
endSessionDialog, so provide a parameter that allows classes
to override this behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=697295
