Because of the GtkSizeGroup-like trickiness we're doing with
PopupMenuItems, we need to force Clutter to discard its cached size
requests for them any time the menu itself changes size.
https://bugzilla.gnome.org/show_bug.cgi?id=645647
If the BoxPointer changes size (eg, when opening the "More" section of
the network menu), reposition it to make sure it's still aligned
correctly and still completely on-screen.
This is not the right fix for this problem (and causes the menu to be
drawn in the wrong position for one frame). The right fix would
involve a ClutterConstraint, but that would be more invasive, and can
happen post-3.0.0.
https://bugzilla.gnome.org/show_bug.cgi?id=645647
The change to make Notification an StButton (06d2c0af, bug 642978)
broke links, because the link actor would ignore the
button-press-event, allowing the notification actor to receive it and
get a pointer grab, and so the link actor would never see the
button-release-event. Fix that by accepting and discarding the
button-press-event.
https://bugzilla.gnome.org/show_bug.cgi?id=645613
The chat-history-fill-in code had logic to avoid appending two
messages when a message appeared in both the log and the pending
messages. But it wasn't working because of an incorrect object field
name.
Additionally, the code was previously keeping the copy of the message
from the log, and suppressing the copy from pending. But that meant
that once the previous bug was fixed, it would think it had only shown
old messages, and so it would create a source but not notify it. So
fix it to suppress the log message and show the pending message.
https://bugzilla.gnome.org/show_bug.cgi?id=645612
For wired devices (actually, ethernet devices), hide the connection
list when there is only one connection (either automatic or stored).
The device can be operated with the associated switch.
Since device state Unavailable is generic and has substates, instead
of using an hack for carrier, introduce some code that checks both
for carrier and firmware-missing when in that device state, and updates
the UI accordingly.
If a notification was updated while one of its widgets was focused,
it would lose the grab when that widget was destroyed. Fix that by
moving the focus to a safe place before destroying the old widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=643687
We want to minimize focus stealing from the user. If a non-urgent notification
comes in while the user is interacting with the tray, we add it to the tray
and only show it after the user is done interacting with the tray. If an
urgent notification comes in while the user is interacting with the tray,
we hide the tray and show the urgent notification.
https://bugzilla.gnome.org/show_bug.cgi?id=636838
We want to allow the user to scroll through all notifications from
source by using a single scrollbar. We suppress the individual
scrollbars inside the notifications.
As one exception, we keep the original scrollbar for chat notifications
because it has a distinct look, ending above the text entry box.
https://bugzilla.gnome.org/show_bug.cgi?id=611611
Change the way menu items allocate their contents to take text
direction into account, so they're fully reversed in RTL locales,
and St.Align.START / END are respected.
https://bugzilla.gnome.org/show_bug.cgi?id=645524
While we have menu for an app icon open, we want to show the prelight
for the item instead of removing the prelight when the user mouses
away from the item and into the menu, and if there's a tooltip
(like for the dash), we want to show the tooltip immediately when
the menu is popped up.
https://bugzilla.gnome.org/show_bug.cgi?id=642871
It can be useful to avoid sending enter/leave events to the source actor
of a menu: this would be the case when the source actor isn't a menu item
that should participate in menu navigation but rather is some object
(like an app icon) that we want to indicate corresponds to the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=642871
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
