After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 648855 - Use tags and named workspaces
Use tags and named workspaces
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-04-28 08:53 UTC by David Prieto
Modified: 2013-08-18 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Mockup (186.36 KB, image/png)
2011-04-28 09:00 UTC, David Prieto
Details
Mockup (120.74 KB, image/png)
2011-04-28 09:08 UTC, David Prieto
Details
Mockup (303.62 KB, image/png)
2011-04-28 09:17 UTC, David Prieto
Details
Mockup (236.16 KB, image/png)
2011-04-28 09:32 UTC, David Prieto
Details

Description David Prieto 2011-04-28 08:53:44 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.
Comment 1 David Prieto 2011-04-28 09:00:43 UTC
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.
Comment 2 David Prieto 2011-04-28 09:08:12 UTC
Created attachment 186803 [details]
Mockup

Workspaces' names would appear right on top on them, not needing any additional space.
Comment 3 David Prieto 2011-04-28 09:17:40 UTC
Created attachment 186804 [details]
Mockup

Tags could be added to apps or files via their right-click menu.
Comment 4 David Prieto 2011-04-28 09:32:10 UTC
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/
Comment 5 ecyrbe 2011-06-17 04:39:05 UTC
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.
Comment 6 Jasper St. Pierre (not reading bugmail) 2011-06-17 07:03:40 UTC
(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.
Comment 7 David Prieto 2011-06-17 08:44:56 UTC
"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.
Comment 8 Allan Day 2013-08-18 15:55:21 UTC
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!