Show "Hardware Disabled" when disabled by HW switch, and
generically "Disabled" when airplane mode is active, as
indicated by v4 mockups.
Note that bluetooth is not affected by NM handling of airplane
mode (and generally the firmware makes the USB bluetooth
adapter disappear when rfkilled), so this is in NMDeviceModem
instead of NMConnectionDevice.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
Since commit 1242a16265, we will use a fake prompt which
cancels alls requests without dialog when the keyring component
is disabled. However this does only apply to new requests, dialogs
that are already active when the session mode changes are kept
open. This is not quite as expected, so cancel the prompt in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=708910
The property is on the NMClient, not NMDevice. Also, make sure
we disconnect the signal when the item is destroyed.
Also, connect to wireless-hardware-enabled, which we'll use soon.
https://bugzilla.gnome.org/show_bug.cgi?id=709635
Destroying the notification will make the key focus be reset to NULL, which
means that gnome-shell will try to focus the MRU window, thinking the user is
done interacting and wants to go back to whatever they were doing.
Unfortunately, since we focus two windows at the same time, they will have
the same timestamp, meaning that the window that actually gets focused will
be a race as to whoever responds to their WM_TAKE_FOCUS event last.
If we explicitly set the focus beforehand, then gnome-shell will believe it
got key focus taken away from it, and won't try to focus the MRU when the
key focus drops to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=703265
We must reduce the forWidth in the call to get_preferred_height()
with the border width, otherwise we might request a smaller height
that we actually need and overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=696564
If the active connection for the device is not the primary or
activating globally, it won't have the _connection and _primaryDevice
expando properties, so grab them from the settings object.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
The patch fixes the following warning, and along with it, the proper
destruction of the NMConnectionSection is performed so that items get
correctly removed from the menu.
(gnome-shell:24528): Gjs-WARNING **: JS ERROR: TypeError:
this.statusItem is undefined
NMConnectionSection<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:173
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMConnectionDevice<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:292
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMDeviceModem<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:448
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._removeDeviceWrapper@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1421
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._deviceRemoved@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1416
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
https://bugzilla.gnome.org/show_bug.cgi?id=709248
Don't assume that this._bgManagers.push() (i.e adding to the end) is always
correct.
On startup we call _createPrimaryBackground which passes in the primary index
which may not be 0.
We connect to the changed signal in _init() but never actually disconnect from
it. The callback has a reference to "this" which results into the background
object not getting garbage collected.
Fix that leaks by disconnecting in _destroy()
https://bugzilla.gnome.org/show_bug.cgi?id=709263
The cover pane is used to block events during transitions, but as
workspaces don't share the same container as other overview elements,
they are currently excempt from the event blocking.
Move the cover pane to the top-level overview container instead.
https://bugzilla.gnome.org/show_bug.cgi?id=709034
Moving the mouse fast enough during xdnd will trigger a xdnd-leave event
because the input shape is not updated until after the animation is done.
So simply ignore the leave events while the animation is in progress.
https://bugzilla.gnome.org/show_bug.cgi?id=708887
This reverts commit e31693bbee.
This doesn't properly adjust the allocation, leading to an unbalanced
overview where things aren't centered properly. Just revert for now,
and we'll rethink this next cycle.
When coming back from search or apps, the workspace thumbnails and dash
don't slide in but "pop in". This is because of bad timing: when slideIn
is called, we immediately start the translation animation, and it
completes before by the time we fade the new page in.
Fix this by calling slideIn and slideOut at two different times: we now
slide out when the old page with our controls is fading out, and slide in
when the new page with our controls is fading in.
https://bugzilla.gnome.org/show_bug.cgi?id=708340
Activating the GDM login screen switches VT and causes X to freeze
event processing (because it lost the drm master), so must make
sure to have painted the lock screen at least once before proceeding,
or the user can go back and see the unlocked desktop.
https://bugzilla.gnome.org/show_bug.cgi?id=708051
gnome-keyring provides a fallback in case our builtin prompt fails
to register, so keyring dialogs may still pop up even when they
are supposed to be disabled.
Instead, keep the prompt registered but cancel requests immediately
while disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=708187
Have AT-SPI calls time out after 250ms, to mitigate the effect of a
deadlock when querying another application that is trying to query
gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=708387
We don't want password entries to grow when entering more characters
that fit the available width; as labels' ClutterText ellipsizes by
default, the password labels allow entries to grow by shrinking.
Setting the appropriate ellipsize mode fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=708324
We don't want the password entry to grow when entering more characters
that fit the available width; as labels' ClutterText ellipsizes by
default, the password label allows the entry to grow by shrinking.
Setting the appropriate ellipsize mode fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=708324
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
We already do this for looking glass, but it makes even less sense
for the normal run dialog - if a mode sets runDialog to false, the
intention is to not allow executing aribitrary commands.
https://bugzilla.gnome.org/show_bug.cgi?id=708218
Previously the animation was not entirely according to the mockup.
Now we are closer to the mockup.
The padding for the indicators are decremented, since we need that
to make the animation not too quick. As a drawback, maybe visually
is not as good as before, or the area to click dots is too much little.
Just make that change for now and test it widely, and we can change
that after.
https://bugzilla.gnome.org/show_bug.cgi?id=707565
The original position was calculated with the stage and the
transformed position of the indicator when mapped. The values
were wrong on some situations, so lets calculate the position
based on the dots width.
https://bugzilla.gnome.org/show_bug.cgi?id=707580
We currently update workspaces geometry when we are notified about
allocation changes of the overview group; however as the geometry
is based on stage coordinates, we miss notifications when the
allocation relative to the parent is unchanged, which happens when
the primary monitor's position changes but not its resolution.
Use a custom layout manager to give us a signal that is emitted
reliably.
https://bugzilla.gnome.org/show_bug.cgi?id=708009
We need to adjust the offset of close buttons, in case the box
pointer has the arrow at the top. To do so, extend close buttons
to hook into a boxpointer (since that's the common use for them)
and automatically adjust their position.
https://bugzilla.gnome.org/show_bug.cgi?id=707842
Gdk uses Xwayland, so it only sees the events we forward to X11
clients. Instead, we can use the abstraction API provided by
mutter and get the right value automatically.
Also, we need to use MetaCursorTracker to handle the cursor
visibility too.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
I thought that cancelDrag was called for completed drags as well,
but it's not. Move the updateHoverId source removal to dragComplete.
This fixes "this._dragActor is undefined" warnings after completed
drags.
https://bugzilla.gnome.org/show_bug.cgi?id=707935
For extremely silly reasons with how the class framework works, the wrapper
method requires "this" to be bound in order for it to work, or else we'll
emit errors in strict mode.
https://bugzilla.gnome.org/show_bug.cgi?id=707892
It is expected that the primary and secondary icons in entries
change places in RTL locales. When doing so, the edit-clear
icon must be replaced by an rtl variant too.
http://bugzilla.gnome.org/show_bug.cgi?id=705779
Before, separators naively checked whether their siblings were visible
using actor visibility. However, if section actors are visible but have
no visible children, this will fail. Special-case separators when doing
visiblity checks.
https://bugzilla.gnome.org/show_bug.cgi?id=707801
When we show(), we need to make sure that the hiding animation
doesn't reach the end, otherwise we would hide the actor but
still have _visible = true.
We were relying on tweener overwriting to do this, but it
doesn't quite work, so better be explicit and do it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=707814
Just as we do in AllView, we set the offset of FolderViews' fade
effect so that no icon is faded when a full page is visible.
This works fine in AllView, however in the FolderView case where
the popup's offsets eat away from the available fade height, the
effect ends up being barely noticeable at all.
While it is not ideal to apply the fade to the edge of a "full page",
it looks less ugly than the current state, so pick the lesser evil ...
https://bugzilla.gnome.org/show_bug.cgi?id=707662
Since now if you focus the indicators, you can't scroll and
change pages in the app picker. That was reported as odd from
some users/developers.
So allow to scroll when the focus is in the indicators.
https://bugzilla.gnome.org/show_bug.cgi?id=707609
A11y users who use the magnifier may have trouble
focusing when they're typing or trying to keynav.
Implement a new system so that they can have the
magnifier track the caret and focus instead instead
of just the mouse.
Bug https://bugzilla.gnome.org/show_bug.cgi?id=647074
While this is good style anyway, after the latest appDisplay changes
the first call to get_preferred_height() happens before we properly
compute those properties, resulting in a size request of NaN that
triggers a Clutter warning.
ClutterActor::scroll-event has a boolean return value to indicate
whether the event has been handled, or event emission should continue.
Now that we are using an StScrollView, we depend on this to avoid
propagating the event to the view's own handler.
https://bugzilla.gnome.org/show_bug.cgi?id=707409
It doesn't make sense to show the indicators in that case, so
don't show them. This has been the design in the first place,
but the code that did that was lost at some point during review ...
https://bugzilla.gnome.org/show_bug.cgi?id=707363
The frequent view is not useful when it doesn't contain any applications
yet. While the previously added label makes this state appear less like
an error (OMG, my apps are gone!), it doesn't address the issue of
usefulness - default to the more helpful All view in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=694710
Similar to adapting the spacing dynamically to the available
space we already do, scale down icon sizes if the grid is too
small to fit the requested minimum number of rows/columns.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
IconGrid has never really been a general purpose container, but has
always been used in conjunction with BaseIcon. IconGrid will soon
gain the ability to adjust the item size dynamically to adapt to the
available space, which will require that we can make some more
assumptions about the items added to the grid (namely: we need
access to BaseIcon's setIconSize() method).
So change addItem() to take an object instead, which should have
an actor and a (BaseIcon) icon property.
Based on a patch by Carlos Soriano.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Add methods to open/close extra space for n rows. The app picker
will use those to make AppFolder popups appear inline with the
main grid rather than on top of it.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
The popup of the FolderView is now contained inside
the parent view, solving the overflow of apps with a ScrollView.
Also, solved a lot of bugs in popup/FolderView calculation
of position and size.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Add a property to also add the calculated spacing
around the grid.
This will allow FolderView to be aligned with the
main grid without cutting off any of the surrounding
boxPointer decorations or the close button
https://bugzilla.gnome.org/show_bug.cgi?id=706081
When we adapt the grid to different display sizes,
we don't want the number of displayed items to get
too small. In the future we will scale down icons to
make sure that the grid fits add least minRows
x minColumns items, but for now we only take the
properties into account when calculating the dynamic spacing.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Organize applications in AllView by pages using the new PaginatedIconGrid
added previously. Pagination is generally a better pattern for collections
than scrolling, as it better suits spacial memory.
Hook into AppDisplay's allocation function to communicate the available
size to the different views before child allocations - this is only
required by the paginated view (as pages must be computed before
calling get_preferred_height/get_preferred_width), but doing it for
all views will guarantee that their dynamic spacing calculation is
based on the same values.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Since the parameter of the function is the width, reflect that in
the function name. Also, since we are counting columns, not only
children for each row, reflect that in the function name also.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
The new PaginatedIconGrid class acts as a container for pages.
So the new class provides the container behaviour and some
useful functions like positions of pages, number of pages, etc.
But, it doesn't add indicators of the pages and doesn't manage
the scroll of the pages, neither any management of the pages
like in which page currently it is, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
This method, which accepts a .desktop filename, is used to highlight
a specific application in the overview, for example because it has
just been created or installed.
https://bugzilla.gnome.org/show_bug.cgi?id=654086
We added special code to sort each row in the overview so that
windows were less likely to cross lines, but the awkward control
flow meant that everything but the last row got sorted.
https://bugzilla.gnome.org/show_bug.cgi?id=707197
Activating the overview is fairly easy (hot corner, <super>), so doing it
automatically after closing the last window on a workspace does not save
a lot of effort; it does result in a surprising context switch when the
user does not expect the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=662581
We watch changes in the VPN state, not the active connection state,
so if we use the active connection state, we might miss an update
(because the VPN property is notified before the other one)
https://bugzilla.gnome.org/show_bug.cgi?id=706262
Descriptions are only added after all devices are read (thanks
to the disambiguation in libnm-gtk), but we use them immediately
when we call _sync() in various points (such as checkConnection())
https://bugzilla.gnome.org/show_bug.cgi?id=706262
Build gnome-shell for x11, and gnome-shell-wayland for wayland
(as well as the associated libgnome-shell and libgnome-shell-wayland).
The first one links to libmutter, the second to libmutter-wayland.
libgnome-shell and libgnome-shell-wayland are now compiled from
libgnome-shell-base (with all sources that are independent of mutter),
libgnome-shell-menu (with the copy-pasted gtk sources), plus the
sources that use mutter API
https://bugzilla.gnome.org/show_bug.cgi?id=705497
These cause annoying allocation cycle warnings, and it's simpler to
just express our desired layout in terms of nested containers.
Adapt the theme to match as well.
https://bugzilla.gnome.org/show_bug.cgi?id=706843
We slide the shield over it, so the animation is rarely seen, and
since no other actor is under the lock screen, the not-cleared stage
can show through, causing weird issues when trying to blend.
https://bugzilla.gnome.org/show_bug.cgi?id=706841
When we implemented the new designs, we lost the ability to suspend
from the system menu. Re-enable this ability by re-adding the hidden
"Alt" shortcut item.
https://bugzilla.gnome.org/show_bug.cgi?id=706612
We show a lightbox when we suspend, to animate the fading to black
caused by turning off the monitors, but we need to hide it when
coming back, otherwise the user is just staring at a black screen
it until he moves the mouse or presses a key.
https://bugzilla.gnome.org/show_bug.cgi?id=706654
Sometimes gnome-session hands us a bad object path for JIT inhibitors
it creates for XSMP clients. While this is a bug in gnome-session, we
shouldn't show an empty-looking dialog here.
https://bugzilla.gnome.org/show_bug.cgi?id=706612
When locking manually (or locking with an animation), fade the
screen to black after a small timeout. This provides a smoother
experience, instead of abruptly turning off the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=699112
Unfortunately, display configuration can and does fail, due
to unspecified HW constraints, drivers bugs, unsupported exotic
configurations or just bad luck.
So when the user makes a change in the control center, show
a dialog asking him if it looks OK, and revert back after 20 seconds
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=706208
All our modal dialogs are given a fixed width and grow vertically
as necessary. Set the request mode accordingly, so that wrapped
labels are considered correctly during size request, and not only
at allocation time (where they'll either take away from the padding
or even cause the dialog to overflow).
https://bugzilla.gnome.org/show_bug.cgi?id=704015
The only point of using a custom container here was to prevent StBoxLayout
from enforcing the wrong request mode based on the orientation. With that
issue fixed, we can simplify the checkbox widget significantly.
https://bugzilla.gnome.org/show_bug.cgi?id=703811
Replace more direct XFixes usage with a the appropriate abstraction
API from mutter, which is guaranteed to work in wayland too.
It doesn't yet replace pointer position tracking, although probably
it should.
Also, because now we're using Mutter API, we lose the standalone
test case.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Mutter now includes an object with the same purpose and functionality
as ShellXFixesCursor, so we can replace our XFixes code with it
and work under wayland too.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Triangles should be flipped in RTL. This is the easiest way to do it that
doesn't rely on modifying the rotating logic, though it is a bit hacky since
the ClutterActor "scale-x" property technically considers the lower bound
to be 0. It works, though.
GrabHelpers use a 'captured-event' to steal events and emulate
modality or grab-like semantics. There can be issues when you try to
use multiple GrabHelpers stacked on each other. As Clutter follows
the DOM-like semantics of "first come, first serve", when a second
GrabHelper connects to 'captured-event', its callback will only be
processed *after* the first GrabHelper's callback is called.
This breaks the expectation of narrowing modality where new modals
take priority over the old ones.
Solving this globally in a cleaner manner would require a rewrite of
pushModal/GrabHelper. As a stopgap fix for now, use one shared
'captured-event' handler between all GrabHelper instances, and
delegate to the individual GrabHelpers.
https://bugzilla.gnome.org/show_bug.cgi?id=699272
This commit detects when a user inserts a smartcard,
and then initiates user verification using the gdm-smartcard
PAM service.
Likewise, if a user removes their smartcard, password verification
(or the user list depending on auth mode and configuration) are initiated
https://bugzilla.gnome.org/show_bug.cgi?id=683437
This commit introduces a new BeginRequestType enum which gets
passed to the 'reset' signal to specify whether
a username should be provided to the begin() method and changes
the loginDialog to comply.
Currently, the signal only ever gets emitted with
AuthPrompt.BeginRequestType.PROVIDE_USERNAME
but that will change in the future when providing smartcard
support.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
We currently emit "failed" any time the UserVerifier is reset,
and user verification didn't succeed prior.
A more conceptually clear time to emit "failed" would be if
the UserVerifier is reset and user verification failed prior,
and to emit "failed" if the user cancels unlock.
This commit restructures things to do that. Aside from being
more conceptually clear, it also lays the groundwork for us
to be able to reset the unlock screen without failing.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
If we don't have a connection at startup or we transition from
having a connection to not having a connection, we need to make
sure we hide the correct indicators.
_updateState has a lot of variables that sort of gunk up the
code and make it more unreadable than need be. Clean up the logic
a lot by moving those variables into the places that they actually
matter, renaming them to remove prefixes, and remove some conditions
that are always met.
Right now the code chooses to animate based on whether or not the
notification was "removed", which is quite a sketchy subject. For
now, add an additional case so that we don't animate when we transition
to the lock screen.
When the triangle rotates (when sub-menu is expanded), it seems as if
the triangle pivots from one corner even though rotation center is set
to Clutter.Gravity.CENTER. Hence the rotation center is set nearer to
the edge than to the corner ([0.3, 0.5] instead of [0.5, 0.5]) so that
it doesn't appear odd.
Also pivot_point is used instead of rotation_center_z_gravity as it is
deprecated.
http://bugzilla.gnome.org/show_bug.cgi?id=703109
This will replace the indicator painted on the stage right now.
This unfortunately does not work for the recorder triggered by the
keybinding -- we'll simply replace the in-shell code with a keybinding
powered by gnome-settings-daemon.
The existing app menu was a kludge of legacy code that tried to manage
a bunch of state, and had a number of issues:
* It didn't properly manage visibility when combined with multiple
apps and the overview.
* It didn't properly manage reactivity when tabbing away from a busy
app to another app.
* It didn't properly disconnect signals when going from one app
to nothing.
and countless others. Rewrite it to use the new "sync" code pattern,
where we centralize all state management and do transitions from that,
rather than strange and quirky control flow.
https://bugzilla.gnome.org/show_bug.cgi?id=705898
Make the lock dialog group reactive, to intercept any events
before they go to the actors below.
In the future, we may restructure our chrome to have a clear
layer system, but for now it fixes a security issue in the lock
screen (you can see the contents of the windows by dragging
if the screen was locked with the overview active)
https://bugzilla.gnome.org/show_bug.cgi?id=705840
There's only two uses of the parameter left, which can easily be added as a
separate line below. Since it's really a private interface meant for the
indicators, make it private as well so external users are less likely to
use it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
To align the arrows, we need to allocate panel buttons the full
height of the tray. Fix up all of the panel buttons to support this,
and align the arrows in the middle.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
Swap out the implementation of SystemIndicator with a dummy,
and build the aggregate menu. At the same time, remove the
poweroff and login screen menus, as those were fake aggregate
menus beforehand.
We lose some flexibility as we lose session-mode-based menu
layout, but as each component of the aggregate menu is supposed
to be "smart" in response to updating itself when session
state changes, I believe it's better than a declarative model.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
We can't silently replace the old behavior of separate status
icons into a new system. Replace SystemStatusButton with a new
SystemIndicator class which will allow for the flexibility we
need. For now, make it a subclass of Button so that it mostly
feels the same, but we'll soon be swapping it out with a dummy
implementation that the aggregate menu will use.
I think the code cleanup here is worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
This code is too complicated to keep, and the last straw came after the
fixed width menu in the aggregate menu design.
This will break some existing popup menus that rely on the fixed width,
but this will soon be replaced with the aggregate menu. We'll also soon
clean this up further by replacing PopupBaseMenuItem's custom layout code
with an StBoxLayout.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
Showing the new message at full size marks an abrubt change and looks
bad. Instead, gradually animate from 0px to full natural height.
Includes hacks to workaround flickering scrollbars while the animation
is in progress.
https://bugzilla.gnome.org/show_bug.cgi?id=687660
If that fails (which only ever happens in initial-setup mode, which
has no unlock or login dialog), we don't want to go ahead with
whatever we were doing.
https://bugzilla.gnome.org/show_bug.cgi?id=701848
If we don't remove the animation, we might leave a pending call
to _lockScreenShown() which would confuse our state tracking into
thinking we're active when we're not.
https://bugzilla.gnome.org/show_bug.cgi?id=700901
Using a signal handlers causes us to depend on connection order, but
we need the message tray code to run last, so it can notice that
notifications are destroyed when hiding the boxpointer and skip
the broken animation.
https://bugzilla.gnome.org/show_bug.cgi?id=686855
When we shift workspaces to create a blank one for a window or
application, all of the window actors are shifted down. However, some
of these window actors are transient windows attached to a main window.
When these windows are moved to a different workspace, the main window
is moved along with it. When the main window is moved, these windows
are also moved. This creates a double move of the windows.
This double movement leads to unexpected results where workspaces are
collapsed and windows are in incorrect positions.
This patch prevents movement of these transient windows, only grabbing
the main (ancestor) windows to move to a different workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=705174
Remove the Wi-Fi chooser from the menu and put it in a dialog instead.
This frees up the submenu to simply have three items: an rfkill toggle,
a button to show the dialog, and a button to show network settings.
Ideally, we'd autodetect the "needs network" case by user initiation
and automatically show the dialog if needed, but lower-level plumbing
is neccessary, so the menu item to show the dialog is an acceptable
compromise instead.
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Since the network section of the aggregate menu will be shown in the lock
screen, we need to ensure that users can't tweak with network settings or
anything like that.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Replace NMNetworkMenuItem with NMConnectionItem, based on
NMVPNConnectionItem, and replace NMDevice with NMConnectionSection
and NMConnectionDevice.
Since this rips apart NMDevice, and since wi-fi should not be
connection-based, we'll temporarily remove NMDeviceWireless. We'll
add it back in a later commit, along with the new Wi-Fi dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Instead, just add them after they're constructed. This allows us to
not have to pass the connections to each device, and prevents issues
with having to enumerate the connections in the middle of construction.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
Note that this does have an interesting side effect of not showing
network connectivity status on wired. This is intentional, and error
states will still be shown in the top bar when they happen.
This also means that if you're connected to both wired and wireless,
even though wired is the default route, we'll first notice the wireless
active connection, and we'll show that in the top bar. New NM API that
will help figuring out the active connection of the default device is
being implemented to stop this from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
The code is complicated by requiring overflow, and in order to incrementally
improve the code to match the designs, remove overflow.
In the new design, we'll have a fixed number of menu items, and Wi-Fi
will be done by a separate design, so we can't be too concerned with
the menu not fitting on the screen.
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
According to Dan Williams, if firmware is installed the device
will disappear and reappear, and this is unlikely to change any
time soon. Just make our lives easier by removing the tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
I intended to make a few code cleanups, but I apparently forgot
to hook up _updateAccessPoint. Merge it with _activeApChanged,
which is where the notify::active-access-point signal is actually
hooked up to.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
As we only reload search providers on startup or when the sort order changes,
and given the small number of search providers we'll actually load, I doubt
we'll see any speed decrease.
The simplicity of synchronous code is also much clearer, and fully avoids
all the possible bugs about in-flight requests or similar.
This also prevents issues with multiple search providers showing up at once,
which happen when multiple requests to reload search providers get called
immediately, with the existing in-flight async requests never cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=700283
When we reload the remote search providers, we currently try to remove
all remote providers, and then re-scan. It turns out that we sometimes
remove the wrong providers from the remote provider list, causing us to
have some providers not correctly unloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=700283
Similar to our ClutterContainer monkey-patching, we can add some
convenience to existing ClutterLayoutManagers:
- hookup_style() to bind layoutManager properties to CSS properties
- child_set() to set child properties
https://bugzilla.gnome.org/show_bug.cgi?id=703905
Jasper removed the ShellGlobal:stage-input-mode property after its
"last" use was removed. Adapt the (hopefully) really last use of the
property to the recent input changes.
https://bugzilla.gnome.org/show_bug.cgi?id=704095
There's quite a bit of duplicated code between the login dialog
and the unlock dialog dealing with the various signals from the
ShellUserVerifier.
This commit moves that duplicated code into the AuthPrompt.
https://bugzilla.gnome.org/show_bug.cgi?id=704707
The point of fading the icon is to make the text displayed over the
icon more legible. In RTL layouts, the text is displayed on the left
of the icon, so fading the right-hand-side of the icon doesn't work
well.
https://bugzilla.gnome.org/show_bug.cgi?id=704583
This is a regression from splitting the slider out that never got fixed.
Restore the previous (useful) behavior by adding a public API to the
slider that lets us pass an event through.
https://bugzilla.gnome.org/show_bug.cgi?id=704368
We've long had the hasWorkspaces property, but it doesn't seem like
it was ever used. Implement it so that we don't have workspaces in
initial-setup mode.
Since it's difficult to make it change at runtime with a decent set
of semantics, and we never expect that to happen, don't bother
implementing it dynamically.
https://bugzilla.gnome.org/show_bug.cgi?id=698593
commit ea02380c15 made the login
screen stop using ModalDialog. It makes sense for the unlock
code to also stop using ModalDialog, too (for similar reasons).
Now that the login screen's auth prompt code has been separated
out, the unlock dialog can use it to get the buttons and spinners
etc, that it was previously getting from ModalDialog.
This commit drops the ModalDialog usage in the unlock dialog, and
makes the unlock dialog use GdmUtil.AuthPrompt instead.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
Right now when a user types their password to unlock their session
we end up getting an unlock signal from GDM right away. We then
proceed to deactivate the screensaver before the user has a chance
to read his messages.
This commit makes sure we clear out the message queue before processing
the deactivation request.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
logind sends out an "unlock" signal separately when
verification completes and we already listen for that,
so we don't need to unlock on verification-complete, too.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
Add an option to limit the appSwitcher to the current workspace. For users
that use workspaces for task separation this more convient then current
behviour. While having to add an option is unfortunate there is no way to make
both groups happy as workspaces usage differes between different users / types
of users.
https://bugzilla.gnome.org/show_bug.cgi?id=703538
We need to make sure that we reset the opened submenu when we close the
submenu, not trick the toplevel into thinking a closed submenu is the
currently opened menu.
https://bugzilla.gnome.org/show_bug.cgi?id=704336
This way, if a parent is insensitive, all children will be, too.
Though PopupSubMenus will be forced closed, PopupMenuSection needs
the propagation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Doing it at the end has confusing semantics, especially as there is
this point where isOpen is true, but the corresponding open-state-changed
has not been emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
It seems this behavior at one time was intentional, but I (along with
the designers) think it looks ugly having the menu having its insides
shrinking and shifting around while fading out of existence.
There's two cases where we currently explicitly try to animate the
submenu closed -- when an item is clicked inside the submenu, and
when the toplevel closes. This removes both of those.
The user expectation is that submenus will be closed the next time the
toplevel is open even if they were open before, so force submenus closed
when the toplevel finishes fading out, without any animation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
As the aggregate menu will be built out of sections from each
of the menus, we need to ensure that activating an item in one
of these sections can close the main menu, even when it is not
a menu item. The new API also needs to be flexible enough to
ensure that animations can be controlled, like the buttons that
lock the screen or launch a new session.
Port the user menu to use this new API as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
A PanelMenuButton added to the top bar might not be visible at all
times. If it is hidden while the corresponding menu is open, we
currently don't do anything at all, e.g. the menu remains open
pointing to an arbitrary location in the top bar.
Instead, close the menu automatically in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=703540
The event catcher that covers the entire primary monitor during
transitions is currently inside a BoxLayout, relying in its
odd support for fixed position actors.
We already have a proper stack widget in place, move it there.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Currently lookingGlass relies on some odd BoxLayout behavior, which
allows children to use fixed positioning without affecting the parent's
size request. As this behavior is scheduled for removal, add the
looking glass dialog directly to Main.uiGroup.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
The duality of the Clutter's key focus and mutter's window focus has long been
a problem for us in lots of case, and caused us to create large and complicated
hacks to get around the issue, including GrabHelper's focus grab model.
Instead of doing this, tie basic focus management into the core of gnome-shell,
instead of requiring complex "application-level" management to get it done
right.
Do this by making sure that only one of an actor or window can be focused at
the same time, and apply the appropriate logic to drop one or the other,
reactively.
Modals are considered a special case, as we grab all keyboard events, but at
the X level, the client window still has focus. Make sure to not do any input
synchronization when we have a modal.
At the same time, remove the FOCUSED input mode, as it's no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
We can easily implement much of the same behavior ourselves by
keeping track of Clutter's focus events. Reintroduce heavily
modified FocusGrabber to do the work for us.
This will temporarily break when the user selects a window until
we can make gnome-shell automatically set the stage focus.
This also removes our only use of focus grabs, so remove those
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
We can't assume "isActive implies isModal", so there is a risk
of pushing a modal that nothing else will ever pop, because we
take the early return and don't activate the user active watch.
https://bugzilla.gnome.org/show_bug.cgi?id=700901
_updateIcon should not attempt to sync any active connections, as the
icon-changed signal can be emitted in response to something done during
_syncActiveConnection. In the case of VPN, removeActiveConnection would
cause an icon-changed signal to be emitted immediately, but the state
would not be updated, causing us to call removeActiveConnection over and
over.
Explicitly sync all active connections when we know it needs to be done,
and simply make _updateIcon synchronize with the current device's icon.
https://bugzilla.gnome.org/show_bug.cgi?id=703565
This fixes a blue background being drawn when switching the monitors
configuration using hardware keys
(clone/multimonitor/external/internal).
The problem is that the shell gather all background loading requests
under the same meta_background_load_file_async call using one
GCancellable (the first one to come). So when the shell receives a
batch of 12 or so XRandr events, it creates 12 new background managers
which end up trying to load 12 times the same background picture. All
of these requests are batched into the same
meta_background_load_file_async using the first GCancellable received
on the first request. Unfortunately, when the first request is
cancelled by the following event indicating a new monitor setup, all
of the background picture requests are dropped on the floor, and
nothing gets loaded (hence the blue screen background).
https://bugzilla.gnome.org/show_bug.cgi?id=703001
It turns out that picking a 3200x1200 scene on notebook chipsets
every time the mouse is moved isn't exactly the fastest thing. Defer
picking to an idle to ensure that it won't get in the way of keeping
up with mouse events.
https://bugzilla.gnome.org/show_bug.cgi?id=703443
The code that checks for various conditions is confusing and
undercommented. It appears one of the recent refactorings
inadvertedly inverted the sense of the 'hidden mountpoint'
check, and caused autorun to not work for anything that does
not have a 'native root' - which is pretty much all volumes
implemented by gvfs.
https://bugzilla.gnome.org/show_bug.cgi?id=703418
Commit d6cace32 introduced a typo in the left/right arrow side
calculation code that causes in most scenarios (where the monitor
width is greater then the height) to not flip the box when it doesn't
fit inside the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=703403
If the drag action ends after something else has put the screen shield
into a different state we can end up in an inconsistent screen shield
state where the whole thing is empty.
https://bugzilla.gnome.org/show_bug.cgi?id=703126
Commit 16fa186b63 attempted to fix the zoom animation problem
by throwing changes on the floor while the overview is animating. This has
the side effect that we might end up missing some positioning changes causes
windows to overlap the workspace thumbnails.
So revert those changes and fix it by simply by passing
WindowPositionFlags.ANIMATE during the overview animation.
This way the animation works as expected and we don't miss any position changes.
https://bugzilla.gnome.org/show_bug.cgi?id=703105
The top_window_group was introduced for popup windows that should
appear above system chrome, but as the group itself is just a child
of Main.uiGroup, chrome that is added after top_window_group will
still be stacked on top.
At least correct the stacking for actors added via addChrome().
https://bugzilla.gnome.org/show_bug.cgi?id=702338
The class is generally useful, so it only makes sense in panel.js
for historical reasons. Because other parts of the code are
using it, though, problems are cropping up that require a
workaround like:
placeSpinner: function(...) {
/* This is here because of recursive imports */
const Panel = imports.ui.panel;
Panel.AnimatedIcon(spinnerIcon, WORK_SPINNER_ICON_SIZE);
...
}
This commit moves AnimatedIcon to its own file so we can drop that
workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
When the osd window is hidden based on the timeout, it accidentally
left the timeout ID in place. When a subsequent switcher popup came
up, it thought the OSD window was scheduled to be hidden and tried
to re-hide the actor. This caused the tween to be run along with
an extra call to enable_unredirect_for_screen.
When the allocation of the workspacesView changes during the animation we override
the tween with one that does not animate causing the overview zoom animation
not to happen.
Fix that by ignoring the alloactionChanged notification during the overview
animation.
The code here before was trying to play hierarchy tricks to
figure out how to show / hide the events list, which broke
when we rearranged how the date menu was laid out. Simplify
the code here to not be so tricky, and update the CSS to
match the new designs.
https://bugzilla.gnome.org/show_bug.cgi?id=702849
The timestamp timeout specifies how long we should wait before
adding a timestamp to the notification. A timeout of one minute
ended up showing a lot of timestamps, so increase it to 3 minutes.
https://bugzilla.gnome.org/show_bug.cgi?id=687809
If we focus notifications before they're expanded, the body and action
area won't be visible, and the can_focus members like the text entry
will not be able to be focused.
Ensure that all of the all actors that would be in an expanded notification
are visible before we attempt to focus them.
https://bugzilla.gnome.org/show_bug.cgi?id=698778
Migration from old settings can result in a path instead of URI
there. This is technically invalid, but can easily recognize it
and avoid the crash.
Minor changes by Ray Strode
https://bugzilla.gnome.org/show_bug.cgi?id=702121
The status item will go away soon, so make sure the one-time
fire is given its own function. At the same time, only connect
to the signal when the situation actually matters.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
No class in here has this.carrier as a property. Presumably, this was
meant to be this.device.carrier, but since this code is going to be
rewritten soon anyway, might as well just junk the never-working
code for now.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
In order to have event descriptions on multiple lines, but still
maintain proper alignment with the day and time strings, refactor
the whole event list to be one big table. Headers are implemented
as spanning cells, and uneven spacing is a mix of row/column spacing
and cell padding.
https://bugzilla.gnome.org/show_bug.cgi?id=701231
In BlueZ 4, Authorize() was used to authorize both service
and JustWorks authorization requests. In BlueZ 5 these two
have been split into AuthorizeService() for services and
RequestAuthorization for JustWorks devices. Adapt the
Bluetooth code accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=700891
This can be more easily achieved by listening for changes to the
device's active-connection property. VPN will still need support to
track active connections, as it does not have an associated
device. But as VPN can track multiple active connections, the names
"set" and "clear" don't quite fit. Rename them to the more-standard
"add" and "remove".
https://bugzilla.gnome.org/show_bug.cgi?id=701954
The end session dialog was waiting a second before updating
its text to display the timer. It is nicer to show the correct
message from the start.
https://bugzilla.gnome.org/show_bug.cgi?id=702056
We currently monitor the shell's override schema for changes to
the 'dynamic-workspaces' key, which ends up being the wrong
schema in classic mode. With the new ability to use mode-specific
overides, we can finally fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
This will allow the use of mode-specific defaults. For classic mode
we currently implement this with mini-extensions, but this may result
in confusing behavior when settings change due to extensions being
disabled during screen locks (not to mention that those mini-extensions
are hardly an elegant approach).
https://bugzilla.gnome.org/show_bug.cgi?id=701717
We will allow to use mode-specific overrides; in preparation for that,
move the code so that we only override preferences after initializing
the session mode.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
As multiple-connections for a Wi-Fi AP won't fit in the new design,
remove submenus right now. Simply make a simple item that connects
to the first known connection for the AP, which should be the common
case.
https://bugzilla.gnome.org/show_bug.cgi?id=698918
Currently we "only" grab the keyboard when starting a drag operation,
which does not impede keybindings to be processed. This is at best
not harmful (like workspace switching), but may have unintended effects
otherwise - for instance, the hot corner is disabled, so having the
corresponding keyboard shortcut still active is fairly odd (not to
mention that it leaves the system in a confused state).
Fix this by switching to pushModal()/popModal(), which will push a
dedicated keybinding mode for us.
https://bugzilla.gnome.org/show_bug.cgi?id=700877
Currently the clipboard's contents may leak to unauthorized parties by
pasting into the unlock dialog's password entry and unmasking the entry.
Prevent this from happening by clearing the clipboard on lock.
https://bugzilla.gnome.org/show_bug.cgi?id=698922
When the dash does not contain any applications (either favorites
or running), it is currently impossable to add a favorite via DND.
Grow the dash slightly in that case to provide a drop target.
https://bugzilla.gnome.org/show_bug.cgi?id=684618
We currently only keep track of old placeholders when moving past
the dragged app's current favorite position, as this is the only
case where we need to worry about jitter. Still, moving it into
_clearDragPlaceholder() allows us to consolidate code paths, which
is a good thing ...
https://bugzilla.gnome.org/show_bug.cgi?id=684618
The function currently only resets the placeholder position if
there is a placeholder; this is not necessarily true, as the
placeholder may be reset outside _clearDragPlaceholder().
If this happens, the placeholder will temporarily stop working
for the "old" position (and permanently if it's the only position).
Just reset the position unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=684618
Before, the text of those buttons were truncated when the text exceeded
the fixed width we had in the CSS.
Now, we give more horizontal space to the control buttons to match
the maximum text length of all buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=696307
Now that we control our own destiny, I noticed that getResultsToDisplay
is the only user of this._notDisplayedResult, and it's called immediately
after setResults, which is the only thing that sets it. Just remove the
stateness entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Since the provider icon only appears in the list results, it makes
sense for that to be stored with the results class, rather than outside,
triggered by which sort of display it is.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
It turns out that this focus code broke sometime in the 3.6 cycle --
when updating results, the focus is always on the text entry, so this
never gets called. We'll eventually replace it with something that
keeps track of the focused result meta, but for now, remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
While this is a very simple translation right now, soon enough it will
be so that it will have a less crazy "public" API and can do things like
cache result metas.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Since the two paths that call this want to keep the actor in two different
states, it makes sense to just call the one function that's the same between
both individually.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Right now, this doesn't give us very much, since IconGrid and StBoxLayout
have different APIs. But since we want to introduce result caching, it
makes to reduce the duplication we already have so we don't need to add
the code to do so in both places.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
pushResults, and the original async search API, were originally intended
so search results that weren't immediate could be added as they come in.
Since then, we've decided that the design of search results is that they
should finish at once with all results. Thus, the code was modified so
that pushResults always overwrote the current result set. As such, it makes
sense to rename the method so that the name matches the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Commit d0310bd745 blindly replaced global.overlay_group with
Main.layout.overviewGroup, but unlike the former, the latter is
hidden while the overview is not active, which makes it unsuitable
for the message tray's light box. In fact, with the removal of
global.overlay_group, there is no longer a container which may
be used both inside and outside the overview, so we can either
recreate the lightbox each time we show/hide the overview, or
use different lightboxes altogether; this opts for the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=701097
This is a singleton object inside libibus which means that if we
destroy it (e.g. because ibus-daemon got restarted) then, other
library users, like the ibus gtk+ IM module that we also use
in-process, will break.
https://bugzilla.gnome.org/show_bug.cgi?id=699189
Currently we simply set the gsettings key when activating an input
source. This obviously introduces a time window, between the event that
activates the switch and when the switch is complete, under which key
events are being delivered to applications and interpreted according
to the previous input source.
The patches in bug 696996 introduce a DBus API in g-s-d that allows us
to know when an input source if effectively active. Using that and
freezing keyboard events in the X server until we hear back from g-s-d
we can ensure that events won't be misinterpreted after an input
source switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697007
Passkey is the proper name to be used when we are pairing with a Bluetooth
2.1+ device. PIN are only used for older devices which is not the case
here, the message is only shown when dealing with 2.1+ devices.
https://bugzilla.gnome.org/show_bug.cgi?id=697661
Meta laters are invoked in reverse order of registration, so
having multiple laters propagating the geometry cause all but the
first one in the frame (which is usually wrong) to be ignored.
Instead, queue at most one later call, and use the last set geometry
in the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=700853
In order to make sure that the struts and regions are initialized,
we need to make sure that we do with the conditions that nothing
is transformed, like the uiGroup, and that everything is visible.
These invariants broke during a fix to hide the UI until the
system background texture could be loaded. Now, reorder things so
that the system background is loaded, and then the UI is properly
loaded, and so on.
https://bugzilla.gnome.org/show_bug.cgi?id=696159
While the default style works well will a solid handle, using both
border and fill color would be desirable in classic mode. Add the
necessary (optional) style properties to allow this.
https://bugzilla.gnome.org/show_bug.cgi?id=697917
Instead of using the input mode, when the overview is not modal
it should use a Chrome-tracked actor, that is added to the input
region. Because the overview always takes pointer input when
visible, the actor is added at startup, and it is shown and hidden
as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
If we are passed an invalid file template, ShellRecorder.record()
will return a %NULL filename; as the Screencast DBus interface
expects a string return value, we cannot return the value unmodified
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=700842
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>
Some callers of the keyring prompt keep the dialog up while
processing the prompt. Allow the user to cancel the prompt
while in this state.
This is propagated to the caller, who can cancel the operation
in question when this occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=682830
Only ACTIVE or ACTIVATING connections are important when deciding
what icon to show, don't fallback on any, possibly invalid or deactivating,
active connection object.
https://bugzilla.gnome.org/show_bug.cgi?id=676285
Commit e98eb57e3e added flags to expand the dialog's background
stack, which works fine with the current clutter-1.16 branch, but
breaks on clutter-1.14 (as shipped with GNOME 3.8).
Using an St.Widget with a Clutter.BinLayout fixes this, and is more
modern Clutter usage.
https://bugzilla.gnome.org/show_bug.cgi?id=699877
The popup currently has a fixed size based on monitor size. As a result,
the popup's content may overflow if its minimum size is larger than the
popup size. To prevent this, use min-width/min-height for the popup size
so that the popup can grow if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=696523
