GNOME Bugzilla – Bug 110904
Metacity Window Menu could be simplified
Last modified: 2004-12-22 21:47:04 UTC
Having a list of "Move to workspace #" or "Only on workspace #" menu items on the top level window menu makes it uncessisarily long. It would be better to put that list in a submenu of the window menu. So it would look like this: Minimize Maximize RollUp Move Resize -- Close -- Put on all workspaces Move to another workspace | -> Workspace #1 Workspace #2 ...
Submenus are harder to navigate though.
That is true. But only slightly. Only one level down (instead of top level) is not much more difficult. Plus, I believe the other factors outweigh this: I don't think the top level menu should be allowed to grow arbitrarily - which it may if all "move to workspace #" menu items are in the top level. Plus, these menu items will not be used as much as the ones above (maximize, resize, etc). The only workspace-related-menu-item deserving of the top level is "Put on all workspaces" and "Only on this workspace". Also, once it's in a seperate menu-level, it can look like this: 1. Workspace name 2. Workspace name where the 1 and 2 and so on are underlined. Hence, the workspaces always have shortcuts, even after one renames them from their default.
I agree with some of Loban's points here... the menu can get pretty big and ugly pretty quickly. And I do like the idea of numbering the workspaces to give them a mnemonic, like you might do with recent files on a File menu. However, I'm not keen on the idea of burying all the target workspaces in a submenu all the time. For people who use no more than three or four workspaces, which I'm guessing is probably most people, the current menu size is fine and that would be a big inconvenience. Another idea off the top of my head, building on the positional aspect used by the workspace switcher and Ctrl-Alt-Arrowkeys... what if only adjacent workspaces were listed on the top level menu, and the others were in a sub-menu? Then you could even show the relevant keyboard shortcuts like we do for the other functions on the menu. So if the window was currently on the top-left workspace of a 2x2 layout, you might have something like: Move _Left* Ctrl-Alt-Left Move _Right to Workspace2 Ctrl-Alt-Right Move _Up* Ctrl-Alt-Up Move _Down to Workspace3 Ctrl-Alt-Down -- Move to _other workspace > Put on all Workspaces Where the items marked * could either be disabled if we don't want to wrap around workspaces, or just show the workspace name of the target workspace like the others if we do. (If the workspace layout was one-dimensional, you wouldn't bother showing the Move Up/Down items at all.) The wording would need to be better either way, in the example above it sounds a bit like you're just moving the window within the workspace. I dunno, maybe the fact that the menu would change around a lot this way would just be too confusing, but it's something to toy with...
Calum's idea is nice, although I feel it's getting dangerously close to being too complicated. Here's my proposal for a compromise: <Usual stuff> --- Put on all workspaces / Only on this workspace Move to next workspace Move to prev workspace Move to ... | ->> workspace sub-menu (The next/prev workspace menu items will be disabled appropriately when at the last/first workspace). In fact, I like this A LOT. If Havoc approves, I'll try to write a patch.
Seems approximately right, I don't have a hugely strong opinion here, other than we should be sure everyone that cares puts in their .02 so we don't keep changing it back and forth. Maybe give it a couple days then we'll put in a patch. If you do: 1. Workspace name 2. Workspace name It'd be nice to keep the current special-case hack for "Workspace _N" so you don't get "1. Workspace 1" (Right now you *do* have mnemonics if you don't name your workspaces; what I'm saying is prepending the 1 should only happen in the case where we currently don't do a mnemonic.)
funny how in "simplifying" the window menu we end up with something much more complicated...
:-) The wording is misleading. I should have said "shortened" instead of "simplified". Havoc, keeping the special case hack won't work. What if I only rename one of my workspaces? We'll have to keep "1. Workspace 1 ..", it's not so bad. If the menu seems still a bit long (which it is a little, it's only shortened by 1 if you had 4 workspaces), we could get rid of the next and previous menu items. So we are back to "Put on all" and "Move to..." One added suggestion: in the "Move to ..." sub-menu, the workspace the window is currently in should be grayed out, so that it is instantly obvious where the window currently is.
You could get rid of the numbers if no workspace has been renamed, or possibly just add the numbers when the workspace name does not already contain that number somewhere in the string (if it does, add the appropriate mnemonic markup to the number in the string)
Why? Suppose I have 4 workspaces, the third renamed to "Foo" and the 4th renamed to "All 4 One". So the menu will look like this? Workspace _1 Workspace _2 _3. Foo All _4 One Too messy. Just always have labelled numbers in the beginning, which have the mnemonic. Simple and unchanging.
Note that I offered two alternatives. The first one would be: Workspace _1 Workspace _2 Workspace _3 if no workspaces have been renamed, or: _1. Workspace 1 _2. Foo _3. t337 h4><0|? if any had been renamed.
Oh! Yeah, that's fine.
I don't mind if a short submenu is posted in-line, but it gets annoying when it hits more than a handful of items. Maybe there's a way to react to this "simple vs expert" situation automatically? For submenus of up to N (propose N=5) items, inline it. ---- Put on all workspaces. Move to next workspace. Move to workspace 1. Move to workspace 2. Move to workspace 3. Move to workspace 4. ---- Once the submenu has grown, it seems to me that it deserves hierarchy. In the workspace list, this would occur only when users have adjusted the settings beyond the defaults, also indicating a level of interface expertise. ---- Move to another workspace. > ---- \ ----------- Put on all workspaces. Move to next workspace. Move to next empty workspace. Move to workspace 1. Move to Browsers workspace. : Move to workspace 6. -----------
*** Bug 122235 has been marked as a duplicate of this bug. ***
Please don't have a "move to next/move to previous". This would look even more uncomfortable than now in a multicolumn setting. I have the classical 9 workspaces, and frankly in this case I really miss (and would find really more usable) "move to workspace" left/right/up/down. Right now I have to waste time to know on what workspace I want it, even if I rename the workspaces. Maybe when the number of workspace is big,say > 6, left/right/up/down would be better and create a shorter menu.
I like Calum's suggestion of Left/Right/Up/Down better than next/prev which seem vague to me, especially in a grid layout. We do need to preserve the non-redundancy of the numbers, as discussed, should be pretty easy. I'm generally in favor of the change overall.
One item missed in window menu: "allways on top". Puting windows on some workspace is possible also in other ways. I agree with making submenu with workspace list. It is good idea to make submenu every time when you must chose from list of objects.
I was annoyed with Metacity not having accelerators on the "Move to..." menu items. Here's a simple patch to add them.
Created attachment 21512 [details] [review] menu accelerator patch
jrb - patch looks fine to commit, though I'm not convinced it's related to this bug report ;-) Does g_snprintf() exist for a reason? if so you should probably use it.
I'm attaching a patch implementing the consensus here. I'll also include a screen shot for the lazy. The patch first swaps out Roll Up/Unroll for an On Top toggle (the On Top uses a check when it is On Top). The specific workspace moves have been moved to a submenu "Move to Another _Workspace" and the menu accelerator patch that Jonathan did is an you can see integrated. There is now also a set of Move Left, Right, Up, Down items that are intelligent and will appear only when it is actually possible to move in one of these ways.
Created attachment 22606 [details] [review] Implement consensus
Created attachment 22607 [details] screenshot
Bug #126674 contains my suggestion for handling the Move to... items. The particular menu items would be eliminated in favor of using the _Move (Alt+F7) item in a new way. See it for details. The fingerfeel is almost the same.
that's sort of independant; I don't think that we'd want to eliminate the window menu even if we implemented something like that since the keyboard move thing is not very discoverable.
It replaces the Move to... menu items, not the whole menu. I've not yet gotten to my "replace the whole window menu with..." proposal. :-p
that's what I meant. Same argument.
I have some memory in another bug that we wanted a visual indication of on-topness. We might want to be sure there's an open bug to add that to the theme format. Can we call META_MENU_OP_LEFT, etc., something like META_MENU_UP_MOVE_TO_LEFT "NULL,FALSE" should have space after comma in the menu op table. I have some inclination to keep META_MENU_OP_STICK/UNSTICK in the code, but just leave them out of "ops" in meta_window_show_menu. Then we could easily add that menu item, perhaps only for certain window types, without readding translation strings or anything. Patch looks good overall, thanks.
OK, committed with your suggestions.
*** Bug 128087 has been marked as a duplicate of this bug. ***