To keep the app icon from overlapping the panel's (border-image)
border, a custom property for clipping the app menu icon's bottom
was introduced. But if the clip region is set before the initial
icon is set, the entire actor ends up clipped. Also due to the double
meaning of clutter_actor_get_height() (e.g. preferred height versus
allocated height), the clip region may end up too large and the icon
overlaps the panel's border-image.
Fix both problems by updating the clip region on size changes as
well, rather than on style changes only.
https://bugzilla.gnome.org/show_bug.cgi?id=644122
The IP_CHECK and SECONDARIES states should be considered part of the
"connecting..." phase.
DEACTIVATING should be its own stage, but that would break string
freeze, so we just treat it like DISCONNECTED for now.
UNMANAGED needs to be treated differently in 3.2, but it is too late
to fix it for 3.0.1.
https://bugzilla.gnome.org/show_bug.cgi?id=646946
I unintentionally made .desktop->pid association "win" over
WM_CLASS. Fixing this makes the case of ancillary .desktop file
entry points (e.g. gnome-control-center's various shortcut .desktop
files) correctly show System Settings, and not whatever the shortcut
is.
In the future I'd like to have a way to say "this .desktop file
is a shortcut, ignore me" or something.
https://bugzilla.gnome.org/show_bug.cgi?id=646689
Alt+Tab's special case of "switch to the most-recently-used window even if
it's in the same app" is actually an hindrance for users to get a firm mental
model of Alt+Tab. Now that we have Alt+Above_Tab the special case is no longer
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=647907
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
We weren't specifying _ALLOW_REPLACEMENT for anything except
org.gnome.Shell, which created a race - if the exiting process
didn't exit fast enough, the replacing process would fail
to get the name.
https://bugzilla.gnome.org/show_bug.cgi?id=646257
As a side effect of (see bug 642221), we no longer put docks or
transient windows into the hash table mapping windows to apps. The
"focused application" code relied on at least transients being in
there.
Fix this by calling the public API to map a window to an app, which
will at least follow transients. Whether we also want further
matching here (e.g. with window grouping) is another issue, but that
can happen as a different bug.
https://bugzilla.gnome.org/show_bug.cgi?id=647082
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
If a caller sets an StLabel's text to what it already is (as, eg, the
clock menu does), do nothing. Unless the label is editable, in which
case, setting the text has a visible side effect (dropping the
selection), so we don't optimize that out.
https://bugzilla.gnome.org/show_bug.cgi?id=645648
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
Add an uninstall-hook to undo the effect of install-exec-hook, and add
an $(AM_V_GEN) to the rule that copies either gnome-shell-real or
gnome-shell-jhbuild to gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=646730
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
