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 3d4408dce8)
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
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
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
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
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 d21aa0d85f 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
All get_app_from_*() helpers are transfer full, but
get_app_from_gapplication_id() was directly returning the result
of lookup_app(), which is transfer none.
https://bugzilla.gnome.org/show_bug.cgi?id=721439
