GDBusActionGroup api has changed again, adapt to that.
Also, use a GActionMuxer to add the 'app.' prefix to actions,
instead of manually stripping it out of the action names.
In the future, the muxer will also contain per-window actions
with a 'win.' prefix.
By the time the window is first mapped and the app menu button is
synced, we may not have finished reading the menu. In that case,
connect to notify::menu and update accordingly.
GMenuProxy has been replaced by GDBusMenuModel, and the object path
has been moved (now needs to be retrieved from the AppMenu GApplication
property).
Update the test to prefix each action with "app." as documented,
and use a GtkApplicationWindow instead of a plain GtkWindow.
Use the new GApplication support in ShellApp to create the application
menu. Supports plain (no state), boolean and double actions.
Includes a test application (as no other application uses GApplication
for actions)
https://bugzilla.gnome.org/show_bug.cgi?id=621203
GDBusActionGroup and GMenuProxy are new objects in GIO 2.32 that
help with accessing menus and actions of remote applications.
This patch makes it possible for the shell to associate an
application with a dbus name and from that a GMenu, that will
be shown as the application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=621203
The loop can exit with an interval of length one or one of
length zero. In the first case it is correct to check which side
of the interval to return, in the second case no comparison should
be made (since there is only one possible value).
In practice, this usually results in one comparison more than needed,
but in some cases (when the position was past the end of the array),
would call the comparator with undefined.
https://bugzilla.gnome.org/show_bug.cgi?id=666614
When transitioning from gnome-panel to gnome-shell in 3.0 we
lost the ability to summon the wisdom of the mythical fish.
This patch restores this, for the few adepts that are aware of
the magical incantation.
(Not as configurable as the original one, but it's an easter egg
after all...)
https://bugzilla.gnome.org/show_bug.cgi?id=666606
Forcing the icon size will distort it unnecessarily, and will
in any case not work if showing an animation (which is a ClutterGroup).
Instead, set the size on the bin, and make it align its child
if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=666606
grid_width and grid_height were inverted, which caused a crash
in GdkPixbuf code. This was never noticed because the animation
in the panel is a square.
https://bugzilla.gnome.org/show_bug.cgi?id=666606
Previously the code in _accessPointAdded was iterating over the
the network list to find a good place, and at that time, added both
the network to the list and the item to the menu. When I refactored
to call queueCreateSection, I forgot to add code to insert the
network in the list.
Add it now, using the new Util.insertSorted function.
https://bugzilla.gnome.org/show_bug.cgi?id=666429
Adds two new functions, Util.lowerBound and Util.insertSorted,
that take an array, a value and a comparator, and find the
first position at which the value can be inserted without
violating the order, in optimal time.
https://bugzilla.gnome.org/show_bug.cgi?id=666429
By using Main.queueDeferredWork, we can ensure that most of the
menu contents (in particular, the heaviest parts like the list of
wifi networks) are not updated immediately as we receive signals
from NetworkManager. Instead, the menu is rebuilt some time later,
or as soon as the user opens the menu.
This means that it is no longer needed to optimize for the
access-point-added case, replacing a lot of buggy code with a safer
call to _queueCreateSection, which in turn should ensure that the
more menu, if existing, is always at the end and that at most 5 networks
are visible outside it.
https://bugzilla.gnome.org/show_bug.cgi?id=664124
We need to notify when the channel dispatcher calls HandleChannels on
us with a channel we already handle. However, we don't want to notify
if we claim a new incoming channel which doesn't actually have
anything interesting in it yet.
For example, a new channel pops up just to give a delivery
notification. We want (or, need) to handle it but don't want to notify
for it.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=666243
Signed-off-by: Jonny Lamb <jonnylamb@gnome.org>
The window overlays may be shown erroneously if hideOverlays is
called while the corresponding clone has an uncompleted tween which
calls showOverlays in its onComplete handler, for instance when
quickly leaving the overview before the initial overview animation
has finished. To fix, remove all existing tweens when hiding the
overlays.
https://bugzilla.gnome.org/show_bug.cgi?id=666020
When in overview, window labels flicker or are temporarily hidden on a
number of occasions - when simply clicking around the area the windows
are displayed in, dragging a window, sliding in the workspace list,
adding new workspaces etc. This patch makes the label for any window
visible at any given moment when in overview and the said window is
not being dragged around.
https://bugzilla.gnome.org/show_bug.cgi?id=644861
When wifi or wwan are blocked by hardware killswitch, we should not
allow changing the switch (it won't work anyway), and show
"hardware disabled" instead, similar to what we already do in the
bluetooth menu.
https://bugzilla.gnome.org/show_bug.cgi?id=665194
When placing networks in _createSection, we were taking in
consideration that _activeNetwork is always first, by adding 1,
but then kept this offset also for networks following it (normally,
all of them, since _activeNetwork is also the most recently used),
that instead should not be affected by the movement.
This resulted in the menu showing 4 networks + More... instead of
5.
https://bugzilla.gnome.org/show_bug.cgi?id=664124
The three boxes for the ripple animation are visible when created. This
means that the drag and drop code that searches for an actor to handle
the drag can find the ripple boxes instead of the Activities button or
hot corner. The latter can handle drag and drop while the ripple boxes
can't.
This is only a problem if drag and drop is attempted before the ripple
animation has been played: the boxes are made invisible at the end of
the animation. The fix is to just create the boxes invisible.
Instead of leaving the tray covering the whole last pixel row when it's
hidden, hide it completely. This avoids mouse events not being delivered to
application windows on the last pixel row.
To summon the tray we use a single reactive pixel on the corner.
https://bugzilla.gnome.org/show_bug.cgi?id=663366
Some plugin hosts may have junk after the UTF8Characters that we need to strip
off. No current browsers that I know of do this, but it still helps to be
correct.
The dash handles 'window-drag-cancelled', to be able to do the
animations for drag snap-back and size changes in parallel. As
the signal is not emitted for previews in the workspace switcher,
it does not work in that case.
If workspaces-only-on-primary is false, swipe scrolling is now
broken with multiple monitors. To fix, let workspacesDisplay
handle swipe scrolling for all views.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
If workspaces-only-on-primary is false, workspaces should be shown
on each monitor; rather than letting the existing workspaces span
the entire screen, manage one workspacesView per monitor (similar
to the extra workspaces in WorkspacesView when the setting is true).
https://bugzilla.gnome.org/show_bug.cgi?id=652580
Extra workspaces are special, in that they collect windows from
all workspaces for a particular monitor. This matches the default
behavior, but we need more than a single workspace per monitor if
workspaces-only-on-primary is false, so don't create the extra
workspaces in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
WorkspacesDisplay was introduced to manage the workspace objects
and views; however, the overview still accesses the view held
by the workspacesDisplay directly, which is a bit odd.
Add some additional methods needed by the overview, and make the
view a private property.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
When installing an extension at runtime, we accidentally swapped the 'type'
and 'enabled' parameters. While this doesn't directly affect anything right
now, as everything works coincidentally, future patches that look at the
'type' parameter to decide what to do would get the wrong answer.
