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 156251 - Alt-tab popup can start on the wrong window
Alt-tab popup can start on the wrong window
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
2.8.x
Other Linux
: High minor
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks: 155456
 
 
Reported: 2004-10-23 21:41 UTC by Elijah Newren
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: 2.8.x
GNOME version: 2.7/2.8


Attachments
Fix the alt-tab order (3.03 KB, patch)
2004-10-23 21:41 UTC, Elijah Newren
accepted-commit_now Details | Review

Description Elijah Newren 2004-10-23 21:41:30 UTC
Alt-tab always starts with the second window in the list, and alt-shift-tab
always starts with the last.  That makes sense in most cases, because people
don't want to switch to the most recently used window if it already has focus. 
The problem is that it doesn't always have focus.  It is often the case that the
mru window (and indeed no normal window) has focus:
  - In mouse focus mode, it's quite common for no window to have focus since
    windows are defocused on mouse exit.
  - The user can click on the desktop or a panel to cause them to have focus
    instead of a normal window.
  - The fix for bug 151996, which I will be submitting shortly, will introduce
    another case where no window has focus.

In all these cases we should have alt-tab and alt-shift-tab both start with the
first window in the list.  I will attach a patch in a minute.
Comment 1 Elijah Newren 2004-10-23 21:41:55 UTC
Created attachment 32976 [details] [review]
Fix the alt-tab order
Comment 2 Havoc Pennington 2004-10-25 15:37:29 UTC
Comment on attachment 32976 [details] [review]
Fix the alt-tab order

Is it possible for the GList to be empty? Maybe if you have no panel or file
manager? metacity probably shouldn't crash in that case.

Patch looks good, just seems worth checking on the empty screen thing.
Comment 3 Elijah Newren 2004-10-25 16:23:02 UTC
No, it's not possible for an empty GList to cause a crash.  There's two things
that prevent that from happening.  The first is that meta_display_get_tab_next()
has an "if (tab_list == NULL) return NULL;" before attempting to call the
return_tab(forward|backward) functions, and the second is that both of those
functions start with an "g_return_val_if_fail (start != NULL, NULL);"

Committed (to both branches--let me know if that was wrong and you only wanted
it on head).