Inside the Shell, all the UI (including chrome, the overview, and
the actual windows) is not a child of the stage but of a special
ClutterGroup, which is cloned inside the magnifier.
Add function for setting this special actor so that actors added by
St are visible in the magnifier. Nothing yet uses this, but the
tooltip will soon.
https://bugzilla.gnome.org/show_bug.cgi?id=635100
We need to update WorkspacesView._ZoomOut before calling
_updateWorkspacesGeometry() in show(), as otherwise the old
value is kept. This was a problem if we previously left the
overview zoomed out.
The applications have to have a way of keeping resident notifications
updated without unnecessarily notifying the user with the information
the user is already seeing in the application window.
https://bugzilla.gnome.org/show_bug.cgi?id=630847
Make summary sources look more clickable and highlight them when selected.
Highlighting the fully expanded summary source when selected matches the
highlighting in the top bar items and teaches the user that any part of the
expanded summary source can be clicked.
Based on the initial patches by Florian Müllner and Jonathan Strander.
https://bugzilla.gnome.org/show_bug.cgi?id=644788
The lightbox will be sized to the size of its parent container,
so we need to make the parent container reliably the size of the
stage, instead of letting it be auto-sized to the size of its contents.
https://bugzilla.gnome.org/show_bug.cgi?id=644889
Returning true from the event handler seems to avoid getting
duplicate return events; these duplicate events likely are
getting generated by IBus.
https://bugzilla.gnome.org/show_bug.cgi?id=644509
Currently activating a window on a different workspace requires very
long drag distances, which is very inconvenient to use.
Fix that by allowing switching workspaces using the thumbnails which is
consistent with window and launcher dnd and much easier to use.
https://bugzilla.gnome.org/show_bug.cgi?id=643945
Don't do an individual hover fixup for every window overlay, instead
just use the new global.sync_hover() to fix up hovers once we have
finished showing the overview.
Based on a patch from Adel Gadllah <adel.gadllah@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=638613
Main._nWorkspacesChanged was racing with Main._checkWorkspaces.
If _checkWorkspaces won the race, _workspaces was uninitialized.
Because of this, _checkWorkspaces only noticed workspaces
with windows on them, leading it to believe the last workspace wasn't
empty, and added a new, empty workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=645343
In the case where the original actor is destroyed, we don't
show a snap back animation, so we need to destroy drag actor
as we would do in _onAnimationComplete.
https://bugzilla.gnome.org/show_bug.cgi?id=640781
If you have XFixes 5 (and corresponding xserver support) then we
add barriers on the panel and in the message tray corner so that
its easy to reach the corners even when there are monitors to the
sides of the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=622655
If the user clicks a trayicon in the overview, drop out of the
overview before passing the click on to the icon. (We have to actually
wait for the overview animation to complete, in case the icon wants to
get a pointer grab, which it would not be able to do with the overview
active.)
https://bugzilla.gnome.org/show_bug.cgi?id=641853
If the pointer moves on or off the stage while another process has a
grab, we will lose track of it. One example of this is that if you use
a popup menu from a message tray trayicon, the tray will stay up after
the menu goes away, because the shell never saw the pointer leave it.
Add a new method shell_global_sync_pointer() that causes clutter to
recheck what actor is under the pointer and generate leave/enter
events if appropriate.
Of course, we can't actually tell for sure when another process has a
grab, so we need a heuristic of when to call this. Currently we call
it from Chrome._windowsRestacked(), which is not really the right
thing at all, but does fix the menu-from-trayicon case...
https://bugzilla.gnome.org/show_bug.cgi?id=630842
If the user clicks on the title of a trayicon's SummaryItem, forward
that click to the trayicon. Also adjust
gnome_shell_plugin_xevent_filter() so that if the trayicon takes a
grab as a result of this, we don't hide the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=630842
If you run a command from Alt+F2 that tries to get a server grab (eg,
xmag), it will fail if it starts up before the run dialog is finished
hiding.
Additionally, the run dialog currently stays focused while it is
fading out, potentially stealing keystrokes (or causing the user to
accidentally launch two copies of a program).
Change ModalDialog.close() to call popModal() immediately
Add a ModalDialog.popModal method, and call that before running the
RunDialog command. If the command succeeds, close the dialog as
before. If it fails, call ModalDialog.pushModal() to put things back
to normal before displaying the error.
https://bugzilla.gnome.org/show_bug.cgi?id=644857
When right-clicking on an AppWellIcon, the icon will become focused,
which (presumably via style-changed) invalidates its current
allocation, causing "icon.y" to return 0 until it has been
reallocated, messing up our idea of where in the AppDisplay the icon
is. Work around this by calling get_allocation_box() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645162
If there is a monitor to the right it is very easy to overshot the
expanding thumbnails and enter the next monitor. So, in that case
we just always show it.
https://bugzilla.gnome.org/show_bug.cgi?id=641877
Specify x-fill and y-fill true for the bin that contains the status
icon so the status icon will always be sized to our specified icon
size (24x24). This prevents pathological behavior for legacy status
icons embedded in the tray where an initial allocation at 1x1 before
they had content would "stick", and the icon would permanently
end up 1x1.
https://bugzilla.gnome.org/show_bug.cgi?id=634820
Right now, the user status menu always contains actions to logout
and lock the screen, and the user switching action only depends on
the technical availability of the functionality.
All those items should honor the lockdown settings defined in
org.gnome.desktop.lockdown.
https://bugzilla.gnome.org/show_bug.cgi?id=645335
To avoid having hot corners that accidentally trigger when e.g. trying
to hit the panel on the primary monitor we add hot corners only to
monitors that are "naturally" top left (top right for RTL).
For instance, we'd like a hot corner here:
corner -> +-------------
| |
+---------+ |
|=========| |
| | |
| | |
| | |
+---------+------------+
But not here:
unexpected hot corner
↓
+---------+-------+
|=========| |
| | |
| +-------+
+---------+
https://bugzilla.gnome.org/show_bug.cgi?id=645116
The fade effect when switching tabs should only be applied when
switching from a previously selected tab, not when selecting the
initial one - otherwise, the window previews are faded in the first
time the overview is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=644389
When we were knocking off workspace height to fix the ratio problems, we
weren't adding spacing in between workspaces, so they smooshed up against
each other whenever we took height off, causing them to be visible.
Different methos are being used to launch the control-center panels of each
status icon. Standarize on Shell.AppSystem.
This also fixes the network icon using a non-existant Util.spawnDesktop()
method.
Bug #645091
Commit fcfd17e was overzealous when simplifying the previous spinner
animation, as a result the spinner now stays around when switching
to another application while the animation is ongoing.
If a workspace becomes empty due to a window changing to/from the
primary monitor, but not changing its original workspace then we
were not noticing this. This can happen for instance if you drag
a thumbnail window to a non-primary window.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
We clip the entire WorkspacesDisplay to its allocation to avoid things
like the WorkspaceThumbnails sticking out of the primary monitor into
another monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
We used to do this only on automatic workspace switch, but that
doesn't work for the multiple monitors case where we want to reserve
space on the extra monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
We create a Workspace with a null metaWorkspace for each
non-primary monitor, showing the windows on these monitors.
These are saved in WorkspaceView.extraWorkspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
This means a bunch of windows will not be visible at all in the overview.
Those will be added back with per-screen workspaces on the non-primary
monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Notification was connecting to button-release-event to decide when to
be dismissed, which caused problems with widgets inside the
notification that reacted to button-press-event but not
button-release-event. Fix this by wrapping the Notification's table in
an StButton and connecting to 'click'.
https://bugzilla.gnome.org/show_bug.cgi?id=642978
In commit 9bd22dc0, I introduced an API to load an arbitrary
.desktop file, not necessarily from the menu path. It turns
out this function was broken because it created ShellApp instances
that were *different* from ones that were cached normally.
As far as I can tell, we didn't initially use it. Then later
Util.spawnDesktop was created which used this function.
Remove this broken function and all callers; if we're loading
.desktop files from *outside* the menu path, we can look at
readding.
This patch also kills off Util.spawnDesktop in favor of callers
talking to ShellAppSystem directly, now that the latter reports
errors.
https://bugzilla.gnome.org/show_bug.cgi?id=644402
Move the "system notification error" handling out of
util.js, and add it to ShellGlobal so we can start
calling it from across the codebase better (including
C).
https://bugzilla.gnome.org/show_bug.cgi?id=644402
Simplify the accounting of which windows we should dim by checking
the current state of windows rather than trying to track changes,
and by keeping a list of dimmed windows rather than a list of windows
with a dimmed parent. Remove windows from the list of dimmed windows
when they are destroyed.
This should fix problems where destroyed windows could end up in
the list of dimmed windows.
https://bugzilla.gnome.org/show_bug.cgi?id=644167
