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.
_______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
