GNOME Bugzilla – Bug 90143
Workspace number layout
Last modified: 2003-02-23 02:49:08 UTC
Now that bug 90029 is somewhat fixed, I finally have a 2x4 workspace popup. That's really nice. However, the numbering goes like this: 1 5 2 6 3 7 4 8 It'd be nicer if it's 1 2 3 4 5 6 7 8 What do you think?
This is in the spec, needs to be brought up on wm-spec-list.
So on wm-spec-list everyone is unable to come up with a reason why it matters how the spaces are numbered. Do you have a rationale for one way or the other?
Michael Toomin replied with a very thoughtful message about 3 possible options: 1 4 or 1 2 or 4 1 2 5 3 4 5 2 3 6 5 6 6 3 (a) (b) (c) The message is archived here, http://lists.gnome.org/archives/wm-spec-list/2002-August/msg00041.html I like b because the book-like orientation feels the most natural to me. Also, with the current 'go to desktop to the left/right' behavior of metacity, it's also the most 'consistent' with previous behavior (when it is always horizontal). With the other two layouts, you need to use the up/down keys, using only the left/right key cause the movement to 'skip' (you'll have to try it out yourself); with b, as it is, left-right would suffice. This is not a strong argument for (b) at all. After reading Michael's message, I'm not very certain what should be Right(tm) anymore. A 'cop-out' solution would allowing changes to the layout via gconf-editor. However, even if there were to happen, there should still be a sane default. The current behavior is usable, I dunno if it's the best we can do, though. ps. From memory, I think the XP's 'tweakUI' workspace control uses the (b) layout, but I'm not 100% sure.
> I like b because the book-like orientation feels the most natural to > me. Also, with the current 'go to desktop to the left/right' behavior > of metacity, it's also the most 'consistent' with previous behavior So it sounds like you want the next/previous commands to translate directly to right/left commands... but the window managers are supposed to give you right/left commands anyway (in addition to up/down commands). One might also expect the next/previous commands to always traverse the *length* of the workspace-grid... I don't see why they should necessarily correspond to left and right. > (when it is always horizontal). With the other two layouts, you need > to use the up/down keys, using only the left/right key cause the > movement to 'skip' (you'll have to try it out yourself); with b, as it > is, left-right would suffice. This is a bug (bug89373). Try gnome-panel version 2.0.6. The problem that you're observing is different than the workspace ordering. > A 'cop-out' solution would allowing changes to the layout via > gconf-editor. However, even if there were to happen, there should Gconf can't be used since this is part of the freedesktop.org specification, which is beyond gnome. It has to work with kde, etc.
The WM spec now addresses this, needs to be implemented in metacity.
This is all done in metacity except that in workspace.c:meta_workspace_get_neighbor() someone needs to figure out the math and implement the currently-unimplemented workspace arrangements.
Batch adding GNOME2 keyword to Metacity bugs. Sorry for the spam.
Adding PATCH_NEEDED, given Havoc's comment above.
I have a patch sent to me via email.
oughtn't this bug be closed?
Yep, this is all fixed up.