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 143511 - Alt+Tab should show same windows as window list
Alt+Tab should show same windows as window list
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Thomas Thurman
Metacity maintainers list
: 131702 147698 171105 312697 462843 565409 577699 (view as bug list)
Depends on:
Blocks: 155456
 
 
Reported: 2004-06-01 15:01 UTC by Havoc Pennington
Modified: 2020-11-06 20:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Include all windows in Alt+Tab (7.11 KB, patch)
2007-08-03 16:05 UTC, Daniel Seifert
none Details | Review
Daniel's patch, with EWMH-like awareness (12.63 KB, patch)
2007-08-07 00:11 UTC, Thomas Thurman
none Details | Review
Program to tell metacity to toggle modes using EWMH-like hints (1.90 KB, text/x-csrc)
2007-08-07 00:12 UTC, Thomas Thurman
  Details
Daniel's patch, with EWMH-like awareness (12.54 KB, patch)
2007-08-07 00:20 UTC, Thomas Thurman
none Details | Review
Updated patch, with EWMH-like awareness (14.56 KB, patch)
2007-08-07 22:01 UTC, Daniel Seifert
none Details | Review
Updated patch, with EWMH-like awareness (14.63 KB, patch)
2007-08-09 16:02 UTC, Daniel Seifert
none Details | Review
Updated patch, with EWMH-like awareness for metacity 2.20 (13.56 KB, patch)
2007-11-23 08:00 UTC, Daniel Seifert
none Details | Review
Updated patch, with EWMH-like awareness for metacity 2.26.0 (15.03 KB, patch)
2009-07-25 12:29 UTC, Daniel Seifert
reviewed Details | Review
Version of Daniel's patch in git format, which applies cleanly to current trunk (15.08 KB, patch)
2010-05-08 19:19 UTC, Thomas Thurman
reviewed Details | Review

Description Havoc Pennington 2004-06-01 15:01:19 UTC
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124911

For the window list you can choose all workspaces vs. single space, Alt+tab
should automatically follow the window list setting perhaps. May require EWMH
changes.
Comment 1 Havoc Pennington 2004-06-11 02:20:05 UTC
*** Bug 131702 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2004-10-15 00:19:36 UTC
*** Bug 147698 has been marked as a duplicate of this bug. ***
Comment 3 Olav Vitters 2005-04-06 16:54:10 UTC
*** Bug 171105 has been marked as a duplicate of this bug. ***
Comment 4 Olav Vitters 2005-08-05 17:19:15 UTC
*** Bug 312697 has been marked as a duplicate of this bug. ***
Comment 5 Reinout van Schouwen 2005-10-01 17:30:00 UTC
Confirming by number of duplicates (and own experience).
Comment 6 Thomas Thurman 2006-03-08 14:46:03 UTC
So how do we know that the window list has this option turned on? I suspect that reading it out of gconf is not the best way.
Comment 7 Elijah Newren 2006-04-16 00:02:52 UTC
Thomas:  Right.  Reading it out of gconf would assume that the person was running wncklet; they might be using a different taskbar.  For example, some people have used metacity under KDE.  The only way I know of to solve this bug would be to add some new hint to the EWMH.  Doing that means coming up with some proposal, coding it up and verifying it works, proposing it on http://mail.gnome.org/mailman/listinfo/wm-spec-list, and fighting it out there, modifying the proposal as necessary.
Comment 8 Thomas Thurman 2007-08-02 16:46:31 UTC
*** Bug 462843 has been marked as a duplicate of this bug. ***
Comment 9 Daniel Seifert 2007-08-02 18:09:13 UTC
I would second this request, at least as far as the "show all windows in alt+tab" is concerned. For some motivation why I consider this feature important, please refer to bug 462843 (marked as duplicate of this one).

However, I would not tie it to the windows list. For once some people may actually like to have it separate, plus the window list may not be in use and so the setting may not be easily accessible for some users.

Also contrary to the window list the Alt+Tab requires a global MRU list. 

Comment 10 Daniel Seifert 2007-08-03 16:05:56 UTC
Created attachment 93037 [details] [review]
Include all windows in Alt+Tab

Here's a patch against Metacity 2.18.5 that will enable the Alt+Tab to show all windows from all workspaces in a global MRU order. I have not been using this for a long time yet (only done it today), but seems to work. 

To switch back from global to workspace-only Alt+Tab, the lines "tmp = screen->mru_list" (2x) need to be replaced by "tmp = workspace->mru_list" in display.c:meta_display_get_tab_list - this would be the place where a possible user-setting can decide which of the two lists to use.
Comment 11 Thomas Thurman 2007-08-04 03:05:36 UTC
Interesting. I haven't tested it yet, but it looks like it ought to work. I've been working on the code for the setting, and I'll attach that when I have a first draft. Between us we might have got some way towards closing this...
Comment 12 Thomas Thurman 2007-08-07 00:11:05 UTC
Created attachment 93176 [details] [review]
Daniel's patch, with EWMH-like awareness

Here's my plan. The EWMH says that in _NET_NUMBER_OF_DESKTOPS, data.l[0] is the number of desktops (i.e. workspaces) and the other data.l are all zero:

http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2453479

I propose we borrow data.l[1] to represent whether task switching should be across just the one workspace (0, the default as at present) or across the whole X screen (1). The effect of other values is undefined.

The attached is Daniel's patch with this functionality added. It's not very polished yet, and I think possibly I broke something to do with allocation because it segfaulted on me after a while of switching between windows, but it holds up long enough to use and demonstrate the principle. (I would track down what I broke and why, but I figured it's only a demonstration.) Also, in a real system there would have to be some hook into gconf so that the state could be remembered for when the WM next started; I haven't included this.
Comment 13 Thomas Thurman 2007-08-07 00:12:49 UTC
Created attachment 93177 [details]
Program to tell metacity to toggle modes using EWMH-like hints

This is the program you need to actually see the effect.
Comment 14 Thomas Thurman 2007-08-07 00:20:12 UTC
Created attachment 93179 [details] [review]
Daniel's patch, with EWMH-like awareness

Tidied this up a bit.

(Actually, for the benefit of anyone who comes by and tries to debug things, it's possible the memory problems were introduced in Daniel's patch and not in my changes to Daniel's patch; I didn't do any kind of rigorous review of Daniel's original patch.)
Comment 15 Daniel Seifert 2007-08-07 06:12:44 UTC
Actually I am quite sure they were introduced in my patch, as I have noticed these issues as well and I only have my patch in use. I haven't found time yet to track them down, though, will hopefully be able to check up on that later this week. 
Comment 16 Thomas Thurman 2007-08-07 12:02:06 UTC
Proposed on wm-spec-list:

http://mail.gnome.org/archives/wm-spec-list/2007-August/msg00006.html
Comment 17 Daniel Seifert 2007-08-07 22:01:21 UTC
Created attachment 93249 [details] [review]
Updated patch, with EWMH-like awareness

I'm attaching an updated patch as there were still some parts left where only the global mru list would be used (even if workspace-switching was enabled).

Also, I fixed an issue if you do Alt+Tab and release very quickly, this tended to move the selected window to the current workspace - something we obviously don't want. Someone should verify that what I am changing is not breaking anything else (I don't think it does, but then this is the first time I am working on Metacity code).

I've also added some checks, maybe this fixes the crashing issues. I tried to hunt them down but with not much luck. Don't know how exactly to reproduce them, and it never seems to happen when running metacity with valgrind. I will keep an eye on that for the next few days.
Comment 18 Thomas Thurman 2007-08-08 13:43:45 UTC
TBH I don't think there's much chance that the EWMH list will agree that this is a good idea in any form. I'm not sure whether we should WONTFIX this or what.
Comment 19 Daniel Seifert 2007-08-08 14:10:47 UTC
As I read it, their main issue is that they think that data.l[1] usage is not appropriate. There is also a side-discussion on where Alt+Tab is to be handled in the first place.

I don't see how either of this warrants a WONTFIX. We could just drop data.l[1] and use something else for configuration. Also, metacity already handles Alt+Tab so the second point is actually irrelevant - unless you consider removing Alt+Tab functionality completely from metacity ;-)

As far as I can see, nobody has an issue with the general feature of having all windows from all workspaces on the Alt+Tab panel - which is what this bug is about. 
Comment 20 Thomas Thurman 2007-08-08 14:23:39 UTC
Well, they seem to be pretty much against the idea of having EMWH store this information at all. (I agree that their side discussion of what should handle alt-Tab is irrelevant, though.)

So if we're to have this functionality we'll need to add a new gconf key for metacity to turn it on and off, and then talk to the control-center people to make control-center set that key (possibly using the same control that currently sets the equivalent key for wncklet. Havoc and readams seemed to be opposed to this idea, though, and since I can't see any other way around it, I can't really see that we can implement this behaviour.
Comment 21 Thomas M. Hinkle 2007-08-08 14:36:39 UTC
Perhaps this makes for a different bug, but I love the ability built into compiz/beryl to use Control-Alt-Tab to cycle through all desktops vs. Alt-Tab to cycle through windows only on this desktop. 

When implementing this fix, I would at least allow for the possibility of having two different switchers linked to two different key commands.
Comment 22 Thomas Thurman 2007-08-08 17:05:16 UTC
So hold on a second here. Ctrl-Alt-Tab cycles through all windows on all desktops, and Alt-Tab cycles through all windows on this one... and you don't have to turn it on and off with gconf or EWMH or anything... and there are two largish WMs which already implement this? Sounds like a plan and a half to me.

Daniel and any of you other folks who raised the issue who are still reading: would this be an acceptable solution?

Note that we're unlikely to make it Ctrl-Alt-Tab because that's already bound by default, but we could make it Ctrl-Meta-Tab or something instead. And it would be gconfable, of course.
Comment 23 Daniel Seifert 2007-08-09 16:02:19 UTC
Created attachment 93375 [details] [review]
Updated patch, with EWMH-like awareness

Updated patch, with EWMH-like awareness

Yes, this would be fine with me. I would just assign the desktop-wide cycling to Alt+Tab instead, so doesn't really make a difference to me ;-)

Also attached a fixed patch (stupid typo, argh), that shouldn't crash anymore, has been in use for almost a day now, no issues so far (touch wood).
Comment 24 Daniel Seifert 2007-10-20 21:50:41 UTC
Small update on status: I have been using the patch posted in comment #23 (2007-08-09) without further changes and did not encounter any issues/problems since I released it 10 weeks ago. 
Comment 25 Daniel Seifert 2007-11-23 08:00:57 UTC
Created attachment 99515 [details] [review]
Updated patch, with EWMH-like awareness for metacity 2.20

Updated patch for 2.20
Comment 26 Havoc Pennington 2007-11-24 04:39:17 UTC
I liked the idea to just have a separate keybinding for "switch among windows on all spaces" - the latest patch doesn't do that though, it looks like?

It seems most useful, and also less messy in the code, if you can have both current Alt+Tab and a new all-workspaces switching configured at the same time (on different keys). Also this avoids extra control center gunk since the new keybinding would just be added to the big list of keybindings.

Compiz really should use Ctrl+Alt+Tab for going between panels and desktop by default, btw, I think that was based on standard CUA type bindings (maybe not though, I suppose it's possible we just made it up)
Comment 27 Daniel Seifert 2009-07-25 12:29:18 UTC
Created attachment 139199 [details] [review]
Updated patch, with EWMH-like awareness for metacity 2.26.0

I've been using the patch basically unchanged for the last two years. Still hoping this somewhat finds its way into metacity (with proper configuration added) :-)
Comment 28 Thomas Thurman 2010-01-22 18:02:57 UTC
*** Bug 565409 has been marked as a duplicate of this bug. ***
Comment 29 Thomas Thurman 2010-01-22 18:04:50 UTC
*** Bug 577699 has been marked as a duplicate of this bug. ***
Comment 30 Thomas Thurman 2010-05-08 19:18:19 UTC
Review of attachment 139199 [details] [review]:

Sorry for the delay in responding.  I have two questions about this patch:

1) Can't we derive the screen MRU lists from the global MRU list?  If we need to iterate over all the windows on one screen, surely we can just grep the global MRU list for the ones which are on that screen.

2) I don't understand the purpose of this part:

  { "/apps/metacity/general/switch_per_workspace",
	META_PREF_COMPOSITING_MANAGER,
	&compositing_manager,
	TRUE,
  },

Everywhere else you write as though we're picking up the state of this switch from X properties and not gconf, and then there's this part where you add a gconf key anyway, and it updates the state of the compositing manager!

I am about to post a git-ified version of this patch (which doesn't address either of these issues).
Comment 31 Thomas Thurman 2010-05-08 19:19:28 UTC
Created attachment 160603 [details] [review]
Version of Daniel's patch in git format, which applies cleanly to current trunk
Comment 32 Thomas Thurman 2010-05-08 19:21:31 UTC
Review of attachment 160603 [details] [review]:

(review of this patch is in comment 30)
Comment 33 Daniel Seifert 2010-05-08 22:54:31 UTC
Answering the questions in comment #30 means I have to clarify that I am not really that deep into the metacity source code (or any other Gnome component for that matter). Basically I looked into it three years ago just enough to create the first version of the patch. 

When updating to 2.26 I just modified the patch until it worked, I don't remember why I added the gconf setting (but most likely not for a 'good' reason) and it probably can be removed.
Comment 34 André Klapper 2020-11-06 20:06:49 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.