After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722928 - window-tracker: Be more cautious when setting focus app
window-tracker: Be more cautious when setting focus app
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-01-24 19:09 UTC by Florian Müllner
Modified: 2014-02-19 23:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window-tracker: Be more cautious when setting focus app (1.69 KB, patch)
2014-01-24 19:09 UTC, Florian Müllner
committed Details | Review

Description Florian Müllner 2014-01-24 19:09:29 UTC
More fallout from tracking non-interesting windows: when enabling desktop icons, we end up showing nautilus' app menu when the DESKTOP window has focus.
Comment 1 Florian Müllner 2014-01-24 19:09:31 UTC
Created attachment 267148 [details] [review]
window-tracker: Be more cautious when setting focus app

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".
Comment 2 Jasper St. Pierre (not reading bugmail) 2014-01-24 20:12:17 UTC
Review of attachment 267148 [details] [review]:

::: src/shell-window-tracker.c
@@ +485,3 @@
+  while (new_focus_win &&
+         !shell_window_tracker_is_window_interesting (new_focus_win))
+    new_focus_win = meta_window_get_transient_for (new_focus_win);

Hm. Is there a reason we have to track the window in window_for_app for uninteresting windows? Simply allowing the _shell_app_add_window but not the insert into window_to_app seems like a better fix for this to me.
Comment 3 Florian Müllner 2014-01-29 17:25:13 UTC
(In reply to comment #2)
> Review of attachment 267148 [details] [review]:
> Hm. Is there a reason we have to track the window in window_for_app for
> uninteresting windows? Simply allowing the _shell_app_add_window but not the
> insert into window_to_app seems like a better fix for this to me.

I basically see three options:

 (1) track everything, handle focus-app explicitly

 (2) track interesting windows, handle focus-app explicitly

 (3) track "whatever should appear as focus-app"

I don't think (2) makes a lot of sense at all here - we end up with one set of windows that are associated with an app as far as ShellApp is concerned, a different set of windows for the win->app mapping, and yet a different set of windows associated with a "focus-app". (3) is better, but tracking "the set of windows we want to be associated with an application in the app menu" just feels a bit arbitrary (not to mention that it's bound to break again if we need to change the set of tracked windows for some reason in the future).

In the end it boils down to preference, but I quite like how the app->windows mapping stopped to be subtly different from the window->app mapping:
It's not at all obvious that "shell_window_tracker_get_window_app(tracker, window) == app" may be false for any window retrieved via "shell_app_get_windows(app)". Admittedly we have lived with this difference until very recently without many problems, so it wouldn't be the end of the world to reintroduce it. I still think it's nicer not to though.
Comment 4 Florian Müllner 2014-02-19 23:39:07 UTC
Attachment 267148 [details] pushed as 2663e1b - window-tracker: Be more cautious when setting focus app