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
