GNOME Bugzilla – Bug 143511
Alt+Tab should show same windows as window list
Last modified: 2020-11-06 20:06:49 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.
*** Bug 131702 has been marked as a duplicate of this bug. ***
*** Bug 147698 has been marked as a duplicate of this bug. ***
*** Bug 171105 has been marked as a duplicate of this bug. ***
*** Bug 312697 has been marked as a duplicate of this bug. ***
Confirming by number of duplicates (and own experience).
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.
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.
*** Bug 462843 has been marked as a duplicate of this bug. ***
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.
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.
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...
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.
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.
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.)
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.
Proposed on wm-spec-list: http://mail.gnome.org/archives/wm-spec-list/2007-August/msg00006.html
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.
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.
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.
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.
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.
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.
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).
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.
Created attachment 99515 [details] [review] Updated patch, with EWMH-like awareness for metacity 2.20 Updated patch for 2.20
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)
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) :-)
*** Bug 565409 has been marked as a duplicate of this bug. ***
*** Bug 577699 has been marked as a duplicate of this bug. ***
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).
Created attachment 160603 [details] [review] Version of Daniel's patch in git format, which applies cleanly to current trunk
Review of attachment 160603 [details] [review]: (review of this patch is in comment 30)
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.
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.