If the user typed "a", hit up, and pressed enter again, we wouldn't re-set the
history pointer to the end, so the broken navigation would instead go to the
entry before that.
https://bugzilla.gnome.org/show_bug.cgi?id=648765
The mouse-wheel zooming "easter egg" breaks horribly when you
drag a window, due to ugly lightbox reparenting tricks it uses.
For now, just end any zoom before we drag the window around.
https://bugzilla.gnome.org/show_bug.cgi?id=649632
When activating an uninteresting window, the last_user_time isn't updated,
because we aren't tracking the window that the user_time gets updated on.
Hack around this by setting the last_user_time in shell_app_activate when
activating an uninteresting window.
https://bugzilla.gnome.org/show_bug.cgi?id=643302
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
