Since both the hot corner's ClutterGroup and the hot corner's
ClutterRectangle button-release-event is connected to
_onCornerClicked() we must handle it there by returning 'true' to
Clutter or else _onCornerClicked() is called twice which defeats the
HOT_CORNER_ACTIVATION_TIMEOUT logic.
https://bugzilla.gnome.org/show_bug.cgi?id=649427
If you receive a message, a notification will appear. If you reply in
Empathy's chat window before the notification disappears, the
notification is updated with the contents of the message you *just*
sent! We should only update notifications if they're incoming.
https://bugzilla.gnome.org/show_bug.cgi?id=650219
Signed-off-by: Jonny Lamb <jonnylamb@gnome.org>
Connect to button-press-event on the menu item actor, not on the
slider, so any part that is highlighted is also clicked. This means
that click on the left of the volume slider is a rapid way to mute.
https://bugzilla.gnome.org/show_bug.cgi?id=646660
All WPA APs were getting set as WPA2 due to the check for privacy;
WPA/WPA2 APs *must* set the Privacy bit according to the standard,
so we'd never end up in the case for NMAccessPointSecurity.WPA.
Fix that, and also add flags for WPA[2] Enterprise which we'll
use a bit later for the first-time connect case for 802.1x enabled
access points.
Instead of rolling our own code, use new libnm-glib functions to do
the same thing. Requires libnm-glib as of
779215c742bbe29a2c66202ec7e2e6d43edeb8ff (which will be part of 0.9).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=648648
==13810== 11,360 bytes in 1 blocks are definitely lost in loss record 18,574 of 18,765
==13810== at 0x4005447: calloc (vg_replace_malloc.c:467)
==13810== by 0x5191882: standard_calloc (gmem.c:107)
==13810== by 0x51920A7: g_malloc0 (gmem.c:196)
==13810== by 0x4056201: blur_pixels (st-private.c:466)
==13810== by 0x40573B4: _st_create_shadow_cairo_pattern (st-private.c:710)
==13810== by 0x4070746: st_theme_node_paint (st-theme-node-drawing.c:856)
==13810== by 0x3FEFFFFF: ???
https://bugzilla.gnome.org/show_bug.cgi?id=649497
A "cosmetic" code arrangement I requested in code review resulted
in one too few items being removed from the queue for each incremental
chunk of icons added. Fix.
https://bugzilla.gnome.org/show_bug.cgi?id=648739
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
