Re: Named, persistent workspaces

[David Prieto <frandavid100 gmail com>]

Elia,

D-n-D reordering would be great, but would not solve all the problems.
For example, your tag idea has some good points, but I see the
following problems with that approach:

Call it a compromise solution. It could not be *perfect* for your case, but I think it would still help you with it while not changing the current workspace approach a lot (which, unless I'm VERY mistaken and leaving my personal preferences aside, Gnome devs aren't gonna be willing to).

Anyway, let's check these problems out.
 

- it only makes sense in combination with "always open application X on space named Y" code.

Yes, that's the scope. I think it can help in those situations where people use specific apps for a specific purpose, and want their workspace to reflect that.
 

This is not that useful for browsers, editors and all other applications that don't exist in single instance. I can't use such tags for all my work projects, as they all use the same
set of applications.

I'm aware of that. The thing is, I don't think there's a solution for those. You're always going to have to drag their window to the target workspace manually, be it with tags or with permanent workspaces.

I know tags are not ideal for that case, but permanent workspaces wouldn't be either.
 

- I would still need to rearrange the workspaces all the time to keep
them consistent with my memorized set of number-based key shortcuts.
Drag and drop would make it quicker and less tedious, but it's still
an utterly stupid sideffect of the way we identify spaces, inflicting
work on the user for no good reason.

Maybe you could assing a shortcut to a tag, e.g. "logo + m" in order to switch to your "media edit" workspace, regardless of its position on the workspace picker. That would help, wouldn't it?
 

- there is an informative value in an empty box with a label on it: if
my "incoming applications" workspace is empty, that means something to
me (It's something i have to do this week, but I'm done processing
them for today, for example). More than not seeing such workspace in
my list.

That's not my case, but I understand your position. I have to ask, where would you place those empty workspaces? Inside the workspace picker? next to it? Would they have any kind of behaviour, other than just existing and not disappearing?
 

I think that the difference is conceptual: I think that spaces, by
being given a name and purpose, should become first-class citizens.
They have a sense just by being there, as instruments of activity
organization. Whereas you seem to try to re-conduct _everything_ to
the currently running applications and currently open windows.

That's right. Trying to find some middle ground here, though.
 

I can pin down applications I like in the dash, and they don't
disappear when I stop them as unpinned applications do, because I
decided that for my habits that's useful to me. Shouldn't I be able to
do the same with spaces, and would it be so terribly confusing for
users that already have two kinds of icons in the dash - with very
similar behaviours?

 Well, I don't think they're the same case. The mere presence or absence of the apps on the Dash doesn't imply that they "exist" or "don't exist"; the mere presence of a workspace on the workspace picker does.

Besides, bear in mind that the whole "dynamic workspaces" approach is based on one fundamental cornerstone, that the Dash doesn't have: that there is only one empty workspace, always. That one rule defines how the user must expect his workspaces to behave. By adding persistent workspaces you're blowing that one rule out of the water and, honestly, I don't thing the Gnome devs are going to be willing to do that at this point.

That's why I'm trying to find a (partial) solution to your problem, while respecting the rule.