GNOME Bugzilla – Bug 648855
Use tags and named workspaces
Last modified: 2013-08-18 15:55:21 UTC
While I think that the new workspace approach is a huge improvement over the old one, certain uses seem to be having their workflows disrupted by it, as can be seen in the mailing list: http://mail.gnome.org/archives/gnome-shell-list/2011-April/msg00415.html I thought of a way to solve most of the problems these people are having, while still respecting the new approach: using tags, and linking those with named (yet still dynamic) workspaces. Basically, if your daily work involves media editing and you want to automatically keep related tasks in one confined workspace, you can use tags to do so. Via right-click you can tag an app or a file (or ideally, if web bookmarks are ever integrated into the shell, even those) as "media edit". Then, when you launch that app (regardless of the file you're working on) or when you open that file (regardless of the app you're using) they won't open in the current workspace; instead, they will open on the empty workspace, which will then have the text "media edit" superimposed over it. If you open a second app or file which is also tagged as "media edit", it will automatically go to that workspace, so related tasks will always be together. That aside, named workspaces will work exactly as normal workspaces do, that is: they will be created on demand, and disappear when all windows are closed. It would also be useful to allow linking these workspaces to keyboard shortcuts, e.g. pressing "logo+m" in order to switch to your "media edit" workspace.
Created attachment 186802 [details] Mockup Tags could be reached as if they were categories, only that they would be custom ones. They could also be edited or deleted via right-click.
Created attachment 186803 [details] Mockup Workspaces' names would appear right on top on them, not needing any additional space.
Created attachment 186804 [details] Mockup Tags could be added to apps or files via their right-click menu.
Created attachment 186805 [details] Mockup This proposal would be compatible with the planned use of a Desktop (or History) file-focused tab, as seen on Seif Lotfy's blog: http://seilo.geekyogre.com/2011/01/first-public-gnome-shell-zeitgeist-efforts/
I do really love this one. Tagging an application should allow to remove the application categories and allow to browse applications by tags. So you could have a tag search provider, that allows you to search things by tag. really usefull and powerfull concept. Also, a tag management application should be implemented and not directly integrated into the shell to not complicate it too much and keep things simple. Also, the context menu should not show already created tags as this could make the menu too large, but only add a "add tag" to the context menu.
(In reply to comment #5) > I do really love this one. > Tagging an application should allow to remove the application categories and > allow to browse applications by tags. This only makes sense if we make a set of useful, pre-existing tags for applications to use... otherwise the tag browser will be full of "brasero (1)", "Brasero (1)", "CD (3)", "DVD (2)", "burner (1)", "writer (3)", which is worse. Well, we already have those pre-existing tags... they're the categories. And they aren't the most useful, either. > So you could have a tag search provider, that allows you to search things by > tag. > really usefull and powerfull concept. > Also, a tag management application should be implemented and not directly > integrated into the shell to not complicate it too much and keep things simple. > Also, the context menu should not show already created tags as this could make > the menu too large, but only add a "add tag" to the context menu. The problem with this design is that it just loads the problem of organization off to the user: it would take an enormous amount of up-front effort to add tags for all their files and applications before it *might* pay off.
"Tagging an application should allow to remove the application categories and allow to browse applications by tags. So you could have a tag search provider, that allows you to search things by tag." Please note that while I have no specific problem with this approach, it's out of the scope of the original proposal. It does open up a lot of possibilities that are worth exploring, but my suggestion intends to be a simple solution for a simple problem, and does not *require* the user to enter tags, let alone use a standalone app to do so.
Hey David, thanks for the detailed suggestions. It's always nice to hear ideas about how to improve the design of the shell. I share Jasper's concern about this encouraging people to do extra work to manage their windows. One of the key design principles behind the shell is to take as much effort away as possible... that's one reason why we dynamically manage the number of workspaces, for example. I wouldn't object to a 3rd party solution which provided this kind of mechanism, but I'm not convinced that it is something we want in the shell itself. I'm also a bit concerned about the amount of complexity that would be involved; since you'd need some kind of UI for managing tags etc. Thanks again, and keep the suggestions coming!