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
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.
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Third step in the class framework port, now it's the turn of
MessageTray.Source and MessageTray.Notification, as well as
the various implementations around the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
The Lang module in gjs has recently gained a small yet powerful
Class framework, that should help improve the readability of code
when using complex inheritance.
This commit starts porting shell code, by rewriting all classes in
popupMenu.js (and all derived classes) to Lang.Class.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
No idea why connecting a key-press-event to a non-reactive actor
used to work, but some Clutter update broke it. Obvious fix is
to make the actor reactive.
https://bugzilla.gnome.org/show_bug.cgi?id=664582
We prefer to ask the user for his own password. If PolicyKit
is not configured to accept that, try the root password. If
PolicyKit does not accept that either, ask for password of
the first user that PolicyKit _will_ accept. The last case
is a bit broken, but should rarely occur in real-life
configurations.
https://bugzilla.gnome.org/show_bug.cgi?id=651547
If no telepathy accounts have been set up or enabled, the IM status
chooser won't have any effect. To avoid confusing behavior, make
the status selector insensitive in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=662800
ComboBoxMenuItems use ClutterClones to reconstruct the active item
in the associated ComboMenu, so pseudo class changes due to state
changes of the ComboBoxMenuItem don't have the intended effect
(since the actual style information is taken from the associated
ComboBoxMenu item).
As a fix, propagate relevant pseudo class changes to the active
ComboBoxMenu item.
https://bugzilla.gnome.org/show_bug.cgi?id=662799
ComboBoxMenuItems use ClutterClones to reconstruct the active item
in the associated ComboMenu to not impose a particular MenuItem type
in the menu. However, this results in style changes (for instance
those triggered by icon-theme or text-scaling-factor changes) of
the ComboBoxMenuItem not having a visual effect until the ComboBoxMenu
is shown.
As a fix, force a style update on the ComboBoxMenu when the item's
style changes.
https://bugzilla.gnome.org/show_bug.cgi?id=662799
The option was merge with 'visual-bell-type' with the GSettings
port, but the change turned out too disruptive for the universal
access menu / settings panel, so gsettings-desktop-schemas commit
a5819b2a4e9 re-added the separate option.
- replace some left-over references to GnomeSession.Presence.setStatus()
- the correct replacement for GnomeSession.Presence.getStatus()
is *not* GnomeSession.Presence.connectSignal('StatusChanged')
This continues the series of patches for GDBus porting, affecting
all code that accesses remote DBus objects. This includes modemManager,
automount, autorun (for the hotplug sniffer), calendar, network (for
nm-applet only), power, scripting (for perf monitor interface)
https://bugzilla.gnome.org/show_bug.cgi?id=648651
Port org.gnome.ScreenSaver and org.gnome.SessionManager glue code
to use GDBus, and move /org/gnome/Shell/EndSessionDialog to the
GDBus connection, so it is backed by the org.gnome.Shell name.
https://bugzilla.gnome.org/show_bug.cgi?id=648651
Rewrite code acquiring dbus names so that it uses GDBus, and rewrite
ShellDBus so that it is exposed on the GDBus connection. Ports of
the other objects will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=648651
When changing _findNetwork with _findExistingNetwork, I changed
the return value to avoid searching twice for the access point,
and changed some names. I forgot to update all points where those
names were used.
https://bugzilla.gnome.org/show_bug.cgi?id=663278
Previously, we connected to notify::strength only if there was
already a signal connected, and the AP changed (thus, by induction,
we never connected). As a result, the icon became stale and different
from that shown inside the menu (which is correctly updated).
https://bugzilla.gnome.org/show_bug.cgi?id=650007
We must look for the actor under the pointer in the whole message tray and not
just in the notification. This will avoid us to capture focus when a
notification comes up with the pointer on the whole tray area.
https://bugzilla.gnome.org/show_bug.cgi?id=661358
Add "Mute"/"Unmute" option to the right click menu for chats to allow muting conversations
without blocking the sender or disabling all non-urgent notifications. Muting a conversation
prevents the pop up of notifications on new messages from the muted source, while these
messages are still available from the summary notification in the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=659962
SubMenuMenuItems close automatically with their parent, however
closing fails when the parent item is a MenuSection, as those
currently ignore any open()/close() requests.
At some minimal handling by emitting the 'open-state-changed' signal,
so children like SubMenuMenuItems work as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=661029
