Currently, the banner text is always located at the right of the
title - we need to swap those around for RTL locales. Rather than
using the locale directly to figure out the ordering, try to
determine the direction of the title label and let it control the
overall direction of the notification - this way, notifications
generally come out right when mixing scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=646921
In the current implementation of the search entry, when replacing a
selected search term with another term, the first character of the
replacement is prepended to the hint text rather than starting a new
search. This fix makes sure that the focus is not lost when changing
the selected search term.
https://bugzilla.gnome.org/show_bug.cgi?id=636341
When updating search results, the current result set is
recreated from scratch before setting the selection
highlight. This results in two style changes of the selected
item, and as a CSS transition is used to animate the style
change, the selected item flickers if it remains the same as
with the previous search term.
Fix by hiding the result set until the selection is set, to
avoid the transition in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=646019
The addition of _backgroundStack to ModalDialog broke focus
navigation, because it was interposed between the focus group root and
all of the interesting content, but since it isn't an StWidget,
st_widget_navigate_focus() was unable to navigate through it. Fix this
by moving the focus root to this._dialogLayout (inside the
_backgroundStack) instead.
Additionally, in EndSessionDialog specifically, _initialKeyFocus
wasn't being set until after opening the dialog, so it was ignored.
Also change ModalDialog.close() to clear the _savedKeyFocus that
popModal() set, so that dialogs that are repeatedly closed and
reopened will have their focus revert back to _initialKeyFocus each
time.
https://bugzilla.gnome.org/show_bug.cgi?id=646740
The icon set as secondary icon of the search entry depends on whether
a search is active or not - clicking the icon should reset the entry
only in the former case. This is implemented by connecting/disconnecting
the 'secondary-icon-clicked' signal when updating the icon, but an
additional signal connection was left-over when refactoring the search
entry, resulting in clicks on the inactive icon removing the hint text.
Fix by removing the stray signal connection.
https://bugzilla.gnome.org/show_bug.cgi?id=646855
The change to StTextureCache for bug 644142 broke lg's inspector icon,
which was not specifying St.IconType.FULLCOLOR, but was relying on the
fact that SYMBOLIC (the default) would fall back to it. Fix the icon
by specifying FULLCOLOR explicitly.
(We should probably be using a symbolic icon here, but there is no
available icon with a select/pick/point-to/etc kind of meaning.)
https://bugzilla.gnome.org/show_bug.cgi?id=646451
When more than one device exists, we need to reset the section title's
device to null, and in that case we must show nothing (neither the switch
nor the label, but an empty label is OK anyway). Also, we need to
update the device statusItem immediately when constructing it, as we
may not get any state-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=646074
NMDeviceModem._createSection was not checking whether it should have
shown the connection list, resulting in status item shown even if
the device was in an invalid state.
Also, fix a logic error when creating the operatorItem and fix overriding
_clearSection protected method.
https://bugzilla.gnome.org/show_bug.cgi?id=646395
NMApplet connects to each NMDevice's state-changed signal and stores
the signal handler id on the NMDevice itself. However, it was using
the same name as NMDevice itself was using to store the handler ID for
the underlying GObject's state-changed signal, thus overwriting it,
and resulting in *neither* signal handler getting removed if the
device went away. (This probably isn't a problem, since the device is
going away, but it causes a warning.)
Also, at least for WWAN devices, the device state changes to UNMANAGED
immediately before disappearing, but getStatusLabel() wasn't handling
that case and printed a warning instead. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=646708
If you restart NetworkManager, then the list of active connections
is emptied, then comes back with the same GObjects in it. If the
_primaryDevice field isn't cleared on the object, then we won't
know we need to set it back on the device, resulting in the active
device not showing up in the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=646558
A notify signal does not include the new value of the property in
its signature, so the handler was trying to compare a GParamSpec with
a number when updating. Fix it to always retrieve the value from the
object.
https://bugzilla.gnome.org/show_bug.cgi?id=646443
ViewByCategories._removeAll clears the sections, but the filter passed
to view still expects them to exists. Therefore, refresh the view
after the section has been rebuilt and the All filter reapplied.
https://bugzilla.gnome.org/show_bug.cgi?id=645801
Right now, the network menu will overflow the screen if More...
is selected with many access points. As a short-term workaround
for this, add a scrollbar for submenus of panel dropdown menus
if they would cause the toplevel menu to overflow the screen.
- Put the actors in a PopupSubMenu in a StScrollView so we get
a scrollbar if the allocated space is smaller than the height
of the menu. Expand animation is turned off in the scrolled case
to avoid weirdness.
- When we pop up a panel menu, set a max-height style property
on the panel menu to limit it to the height of the screen.
- Hack event handling while the scrollbar is dragged to make
the scrollbar work properly.
https://bugzilla.gnome.org/show_bug.cgi?id=646001
Since the icon area is end-aligned, the signal strength icon for
insecure networks was ending up aligned with the lock icon for secure
networks. Fix that by always including a _secureIcon, but having it be
blank for the insecure networks.
https://bugzilla.gnome.org/show_bug.cgi?id=646121
Adding correct annotations to Gio.File.load_contents revealed that gjs
doesn't actually support array+length combinations. For 3.0 this would
be invasive to fix, so add a method to ShellGlobal which does what
we need.
https://bugzilla.gnome.org/show_bug.cgi?id=646333
Figuring out the size of an unmapped actor is not completely
reliable because styles aren't fully assigned until an actor
is mapped. So show the submenu before computing the size we
want to tween to.
https://bugzilla.gnome.org/show_bug.cgi?id=645949
Some connection types (like wimax) are not supported by the menu, and
should be ignored instead of throwing exceptions. Also, NetworkManager
had a bug that sent connections with invalid settings. This should not
happen, but in case it does, we will not blow up, but just log a warning
and continue silently.
https://bugzilla.gnome.org/show_bug.cgi?id=646355
When a device is connecting, we can continue showing available
connections and access points, as well as the active one with the dot.
(Hiding was a remnant of when the device status was on a different
menu item than the title)
https://bugzilla.gnome.org/show_bug.cgi?id=646381
A cosmetic change recommended in review of the patch to fix the
VPN Connections switch ended up introducing a logic error that
made the switch not work properly. Fix.
https://bugzilla.gnome.org/show_bug.cgi?id=646380
It was always reporting true, even if disconnected. At the same time,
add a signal that is emitted when state changes and update the UI
accordingly.
In the future (with another libnm-glib API break) we should use the
NMVPNConnection object to track the connection state, so that we can
show if we're connecting or we need authentication.
https://bugzilla.gnome.org/show_bug.cgi?id=646380
NMDevice._findConnection expects an uuid as parameter, but
checkConnection was passing a NMConnection object. This caused
exists to be always false, thus the connection was added again every
time the 'updated' signal was emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=645702
When a source has an associated tray icon, we would forward all clicks
to the X11 window, meaning that the summary notification could not
be opened. Instead, restore normal event flow for clicks, when the
source has notifications in the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=645753
Since the opacity of the application menu is controlled by
it's _targetIsCurrent flag, we need to respect that when entering
and leaving the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=645734
Sometimes, log messages are hard to differentiate from normal,
unread recent messages, so give a separate style to messages
retrieved from the TelepathyLogger service.
https://bugzilla.gnome.org/show_bug.cgi?id=645609
If we have a date that's not within the last week, it's really
confusing to display it as "Sent at 9:23 on Tuesday". Steal
some strings from calendar.js for displaying older dates to
avoid a string-freeze break.
https://bugzilla.gnome.org/show_bug.cgi?id=645609
This ensures that we don't show a small black blob fading away
when the user clicks on the notification and it is removed.
Set HIDING state right away in _hideSummaryBoxPointer() so that
it is only called once. Update this._pointerInTray when the tray
is unlocked, so that we are not dependent on escapeTray() being
triggered by 'done-displaying-content' signal.
https://bugzilla.gnome.org/show_bug.cgi?id=645697
Use Meta.later_add() with BEFORE_REDRAW rather than Mainloop.idle_add()
to add the banner body so that the notification body is reliably added
after the first frame is drawn. This is important for notifications that
are expanded right away, such as the summary notifications that
were not shown as banners because the user was in the Busy mode or was
interacting with the summary. Otherwise, these notifications were sometimes
shown with an ellipsized banner and were only getting full content when
they were done animating.
Only add expanded content and signal the change once. Previously, we
used to signal the change numerous times and processing this signal was
holding up processing other things, such as the user moving the mouse
away from the notification so that the notification collapses.
https://bugzilla.gnome.org/show_bug.cgi?id=645719
Since the hotcorner is a reactive actor, and it is over the Activities
button, hovering on it results in a leave-event for the button.
This is not noticeable when opening the overview, as the button is
correctly prelighted, but it is when closing, if you keep the mouse
near the hot corner, as the button is kept in normal state, despite
the mouse being over it.
https://bugzilla.gnome.org/show_bug.cgi?id=645751
Instead of setting the x/y position of the box pointer, which results
in a long change of workarounds for limitations of the Clutter
layout system, set the anchor point instead, which takes the
positioning out of the layout system.
The position is computed as a combination of the position computed
from the allocation and the box pointer's size, and an offset that
we tween when animating showing and hiding the box pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=645744
Using ClutterActor.get_transformed_size() can produce bugs if we
happen to position the box pointer when the source actor has a
relayout queued. Use our newly added reliable utility function
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645744
Commit 31b12635d1 fixed links in notifications again, but blocked
clicks on normal labels getting through to the notification. Fix
this, so that both links and dismissing notifications work again.
https://bugzilla.gnome.org/show_bug.cgi?id=645839
Add a translator comment for the "Sorry, that didn't work. Please try
again." string, as suggested by several people; this should help
translators what "that" refers to.
As a stop-gap measure until we have a native input method tray icon,
add ibus-ui-gtk to STANDARD_TRAY_ICON_IMPLEMENTATIONS so that the IBus
status icon shows up in the status area rather than in the message
tray. The message tray location doesn't work for the function of
showing the current input method when switching between windows or
changing input methods.
https://bugzilla.gnome.org/show_bug.cgi?id=641531
StThemeNode.get_length() doesn't necessarily return an integer pixel
value, and our code produces non-integer positions in that case. So
round the spacing.
https://bugzilla.gnome.org/show_bug.cgi?id=645647
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
