Allison Karlitskaya authored Nov 16, 2014 and Dan Williams committed Nov 21, 2014

Due to a typo we were always removing the first (index 0) connection
from the global list of connections instead of the correct one.

This resulted in some connections remaining in the shell's connection
list long after they were removed.  In particular, this resulted in
multiple copies of a bluetooth connection appearing after suspend/resume
(when the device was readded and the cached connection list was
rescanned).

https://bugzilla.gnome.org/show_bug.cgi?id=740227
(cherry picked from commit 3d4408dc)

We don't need to wait to until the stage window is mapped to take
the modal grab, because that code now runs in a startup-prepared
signal handler, which in turn runs some time after the mainloop
has started and well after the stage window is mapped.

https://bugzilla.gnome.org/show_bug.cgi?id=711682

Disable the effect when GLSL is not available otherwise we will
crash later.

https://bugzilla.gnome.org/show_bug.cgi?id=733623

Typos meant that the orientation service was never detected as running
and that the orientation lock menu item didn't appear.

https://bugzilla.gnome.org/show_bug.cgi?id=733498

Telepathy 1.0 will not be compatible, and will probably require
source changes. telepathy-glib 0.12 and telepathy-logger 0.2 are
the 0.x ABIs (they were the first stable-branches to have g-i).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=721704
Reviewed-by: Giovanni Campagna

If gdk_screen_get_setting fails, like if it's running without XSettings,
then the GValue will have a value of 0. A lot of code tries to divide by
the scale factor. This produces NaN, and combined with the fact that NaN
is "leaky", we very quickly end up spinning out of control.

Currently running the perf tool results into no wm running
afterwards making it hard for the user to get the results from a terminal
and generally does not make it easy for users to run it to gather numbers.

So restore the shell after the test has completed.

https://bugzilla.gnome.org/show_bug.cgi?id=724870

When removing the current workspace, the active workspace is changed
to the preceding one automatically before we change explicitly to the
last workspace. There is no good reason to change workspaces twice in
this case, we can avoid the first one just by changing to the new
workspace before removing any workspaces.

https://bugzilla.gnome.org/show_bug.cgi?id=709064

Update NEWS.

Since we started tracking non-interesting windows, we can no longer
assume that if we manage to find an app associated with the focus window,
it should appear focused - we now can find apps for docks, the DESKTOP
window etc.
To restore the old behavior, make sure that the focus window or one of
its parents is "interesting".

https://bugzilla.gnome.org/show_bug.cgi?id=722928

Otherwise we crash ...

https://bugzilla.gnome.org/show_bug.cgi?id=705410

Revert the hacks that where added in response to a bug caused by
commit ba459f4d

https://bugzilla.gnome.org/show_bug.cgi?id=705410

VNC / XRDP reports nonsensial (i.e 0) monitor dimensions causing us to
end up with a dpi of "Infinity" and thus scale even though we shouldn't.

https://bugzilla.redhat.com/show_bug.cgi?id=1065788

Set the scaling factor when the dpi is above the hidpi threshold.

https://bugzilla.gnome.org/show_bug.cgi?id=705410

Add a scale_factor property to StThemeContext that can
be used to enable (integer) scaling of pixel values.

https://bugzilla.gnome.org/show_bug.cgi?id=705410

The log handler can be invoked at bad times, and in particular
it can be invoked from gsignal with the signal lock taken.
At that time, calling into arbitrary high-level APIs can
cause a dead-lock.
Instead, only send to telepathy the tp-glib debug messages.
Everything else is in the journal anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=724256

Jasper St. Pierre authored Jan 28, 2014 and Florian Müllner committed Feb 06, 2014

If we dispose a ShellApp that has windows left, then we'll crash
when we remove the last window, as that frees and NULLs out
app->running_state.

https://bugzilla.gnome.org/show_bug.cgi?id=723197

So far we have assumed that whether or not a window is interesting
is static. In general this is the case, but as it is legal for the
underlying properties to change at any time, there are of course
offenders that actually do this (flash I'm looking at ya).
While we used the property to determine whether a window should be
tracked or not, the worst case was showing windows that should be
hidden or missing windows that should be shown.
However as we nowadays base an app's running state on the number of
interesting windows, we need to be more careful in order to avoid
ending up with running apps with no windows.

https://bugzilla.gnome.org/show_bug.cgi?id=723308

The code from shell_window_tracker_is_window_interesting() is equivalent
of MetaWindow's skip-taskbar property, so use it to avoid code duplication.

https://bugzilla.gnome.org/show_bug.cgi?id=723308

With the lastest ShellApp changes, an app is considered stopped
when the last "interesting" window is closed. However the app
may still track non-interesting windows, so if we unref the
running state on the state transition, we hit an assertion later-on
when trying to remove the non-interesting window.
Fix this by keeping the running state around until the last window
is closed.

https://bugzilla.gnome.org/show_bug.cgi?id=722840

An app should be considered running if it has at least one "interesting"
window, however the code considers an app running if it has at least
one tracked window. This was fine while we were only tracking interesting
windows, but since commit d21aa0d8 this is no longer the case.
So keep track of the number of interesting windows as well and use that
to determine the running state.

https://bugzilla.gnome.org/show_bug.cgi?id=722690

When restricting the switcher popup to the current workspace, we
filter out running apps with an empty window list (namely: no open
windows on the current workspace). However we may end up with an
empty window list even when not restricting items to the current
workspace when all windows of a running app are associated with a
different application via the transient_for hint.
To fix this, just filter out items with an empty window list
unconditionally.

https://bugzilla.gnome.org/show_bug.cgi?id=722434

It is possible to associate an application's window with a different
application using the transient_for hint. However we currently only
consider the hint in get_window_app() and not when making the original
association, which opens the door to some confusing inconsistencies;
for instance, get_window_app() will not necessarily return the same
value for all windows retrieved via shell_app_get_windows().
Fix this by looking at the transient_for hint when making the original
association, not just in get_window_app().

https://bugzilla.gnome.org/show_bug.cgi?id=722434

Without special-casing, our current spacing calculation results in
negative size requests for empty lists, which will trigger a Clutter
assert later.
While the list is never supposed to be empty, bugs happen; crashing
users' systems is the least graceful way of handling this, so don't
do it.

https://bugzilla.gnome.org/show_bug.cgi?id=722434

If the notification is destroyed between an allocate and the redraw,
the meta_later is invoked on a destroyed object, and fails because
the clutter calls are invalid at that point.

https://bugzilla.gnome.org/show_bug.cgi?id=722547

StWidget::popup-menu is emitted when Menu/<Shift>F10 is pressed,
not released (for consistency with Gtk+), so we need to forward
that. Note that for key press we don't emit the matching key
release, because the app will take a grab and get the event directly
from X when the key is physicall released.

https://bugzilla.gnome.org/show_bug.cgi?id=721267

Update NEWS.

static internal functions should be documented with /*, not /**

https://bugzilla.gnome.org/show_bug.cgi?id=721439