GNOME Bugzilla – Bug 150703
Should indicate the workspace a window is on
Last modified: 2007-05-19 00:13:44 UTC
When opening the menu, I'd like to know what workspace the window is on (especially useful when I have several terminals running, and their "intended usage" depends on the workspace they are on). I have two ideas how to implement it: * Put separator bars between the windows, grouped by workspace (and probably have one separators after another if there are empty workspaces). * Use tooltips on the menu items that tell me about the workspace of (and other possible useful facts about) the window. Thx, nomeata
Nice idea. I'm not sure what is the best solution, though. CC'ing usability people to know if they have a preference between the two.
Any news?
Just to clarify, I assume this only applies when the applet is set to "show windows from all workspaces"... took me a while to figure that out :) There is already a roundabout way to tell (look at the "Move to another workspace" submenu, and see which item is greyed-out), but I'd agree a more direct method would be handy.
I tried something with this a while back, let me attach pretty screenshots :-)
Created attachment 33219 [details] window selector with text above
Created attachment 33220 [details] window selector with text above
Do I see that right: the windows of the current workspace appear on the very top, just like in the current implementation? I like the look of yours. The String "Workspace 1" is the name of the workspace, not just the number, right?
yes and yes. :-)
Bryan: I like this alot! In fact, I wanted to propose something like that myself a while ago, but shrugged it off, because I didn't know if it was possible with the toolkit. Basically, my only comment is; Instead of having it like this: ------------------------------- Workspace 1 Do it like this: --- Workspace 1 --------------- Basically a fieldset with a label.
Created attachment 33246 [details] Proposed Implementation: Screenshot Do you like this layout? This is acutally working code, I've just written a GtkMenuItem that packs two separators and a label where the width of the left separator is twice the height of the label. I'm too lazy to directly use gtk_paint for the drawing process, but it works :). Any usability suggestions?
Sexy! I guess the only thing that could be debated now is whether clicking on the desktop names should switch or not, but I guess that's a different bug.
I'd say no, since a click on any window in that workspace will switch the workspace.
IMHO, Brian's first mockup looks better.
Vincent: I don't like the right-alignment of category labels. This forces you to double-check whether you correctly associated a single category with its items, since the distance to the items themselves distracts you.
Christian: the user opens the menu because he's looking for a window. I don't think his main interest is knowing in which workspaces the windows are, but he may find this informations useful. This is why I think it's better that this information is "less visible" than the list of windows. But remember, I'm no usability expert :-)
Created attachment 33269 [details] Proposed Alternative Implementation: Screenshot Do you prefer this one Vincent?
Calum: Any comments on the usability of those implementation proposals? They behave exactly like they look: The Separator+label menuitem isn't activatable/selectable. Is the purpose of the labels obvious enough? I've explicitly CCed you since I don't know whether you're subscribed to usability-maint.
I really like Christian's first proposal. The simple reasons are: * The workspace name is a heading, and a heading is usually more prominent than its child(ren). * Since it's a set (list), it makes sense to make it so that it resembles the fieldsets (or "frames") already known from the web, Windows, Mozilla preferences, etc. (GNOME dialogs tend to use only the heading, and then indent the contents without having a frame around it, however.. but in Christian's second proposal, it's the other way around - the heading is indented) * I don't like the fact that there is a "new" font size introduced in the other proposals. Anyway, I'm not a usability expert either - I'm just tired and blabbering - so I'll let Calum do the talking ;)
Let's just do it the Free Software way - do it the easies and quickest way, get the code our there, get feedback, do it better with the feedback. Otherwise, we can talk here with no end.
Christian: yes, I like the look of Bryan's mockup (haven't tried out the patch)-- I prefer the first one too FWIW. (I am on usability-maint, btw.) We also need to be careful that any functionality we add here is accessible-- I it needs to work with high contrast and large print themes. And given that the workspace label 'separator' (sensibly) isn't selectable, how can we convey this useful new information to a screenreader user? Perhaps set the accessible description of each menu item to include the window's workspace name at the end, or something? Cc'ing some a11y folks for ideas.
The Window Selector now uses the new WnckSelector widget from libwnck. Moving bugs to libwnck.
Any ally ideas? I see no other way for including this information somewhere in a menu UI. Do we need to rethink the menu scheme we currently try to layout the windows into?
This feature (sorting by workspace and workspace label) should be able to be toggle on or off. Some users might not want to have the extra workspace labels. Anybody followed up on the tooltip suggestion? "Use tooltips on the menu items that tell me about the workspace of (and other possible useful facts about) the window."
I don't think tooltips would be a good idea. As I use workspaces to logically group related windows, I want that grouping be visible in the window changer right away.
Moving to right component. Sorry for the spam.
Created attachment 39754 [details] workspace name and separator modifying with images from Comment #5 and #6, i came up with this image of how i think the menu could look with workspace names and separators
Created attachment 39755 [details] workspace names without separators
What's the progress on this issue? There are a few proposed implementations, what's the next step?
See also bug 342696 for a somewhat related (though still separate) issue that affects the tasklist. Joachim: The next step is getting calum or bryan or mpt to give us a usability decision and then find someone to code it up. :)
Fixed in trunk. I didn't put the workspace name of the current workspace, but I think it's nice as it is right now.
Created attachment 88426 [details] Screenshot Here's a screenshot, for people who don't want to try trunk :-)