GNOME Bugzilla – Bug 663984
Give users the choice between dynamic and static workspaces
Last modified: 2012-08-28 20:33:10 UTC
Hi, The dynamic workspaces are a good idea, a good innovation, but they are not suitable for all uses. Gnome 3 starting to migrate into the testing version of Debian, and there is much discussed on the Debian French mailling list. Many of us use Gnome at home and also at work. We test Gnome 3 at home before, in several months (years :o) ), the migration of professional PC and we are worried. This is a request to have the choice to have a different behavior for workspaces. This is not to want to change the default behavior, the dynamic workspaces. Leave the choice to keep static workspaces with, workspace isolation, an alt-tab to a limited workspace, saving the session with the number of workspace and applications that are in a particular workspace. This should be allowed by Gnome 3 without extensions. In my case, when I start my computer at work, he launched five workspaces, each dedicated to one activity, in each of these workspaces Gnome up applications that are useful for this activity. I am willing to work at the beginning of my session, without waiting, and I can switch from one activity to another without waiting until all applications are ready. Another case reported on the Debian French mailling list is the workspace isolation and alt-tab. The user has multiple workspaces, one for displaying documents to a client and others on which documents should not be visible to the client. With the alt-tab all the documents of all workspace will be grouped and the client sees all. The requirement to use extensions for this basic behavior is annoying, these parameters should be included in the Gnome mainline. The use of extensions created classes of users, those who know that extensions exist and those who are not geek enough to test several extensions before finding the right one. And there are those in business or in schools that can not install extensions, which can only change the setting. Extensions must follow the speed of development of Gnome. They may come into conflict with each other. It's embarrassing for a basic behavior as the management of workspaces, it touches on how to work with the computer. Static workspaces is used in business, and is a way of working. There are many flamewar on the changes in behavior, the use of extensions does not calm these flamewar. By providing the default installation with the choice of behavior, no one has twists. Extensions are not visibility. If you asked someone which desktop he uses, he will answer Gnome, KDE, Xfce, but no such desktop and such extensions. The choice by the developers of dynamic workspaces will be the right choice visible to all, although many people use extensions. Regards.
(In reply to comment #0) > The use of extensions created classes of users, those who know that extensions > exist and those who are not geek enough to test several extensions before > finding the right one. And there are those in business or in schools that can > not install extensions, which can only change the setting. > > Extensions must follow the speed of development of Gnome. They may come into > conflict with each other. > > It's embarrassing for a basic behavior as the management of workspaces, it > touches on how to work with the computer. Static workspaces is used in > business, and is a way of working. > > There are many flamewar on the changes in behavior, the use of extensions does > not calm these flamewar. By providing the default installation with the choice > of behavior, no one has twists. > > Extensions are not visibility. If you asked someone which desktop he uses, he > will answer Gnome, KDE, Xfce, but no such desktop and such extensions. The > choice by the developers of dynamic workspaces will be the right choice visible > to all, although many people use extensions. This will change very soon. Extensions will be visible and very easy to install, very soon.
There are several issues in this report. The workspace isolation thing (bug 650289) can be implemented while keeping dynamic workspaces, and vice-versa. Another problem is restarting all apps on login: this is session management, which is again different from (though complementary to) static workspaces; suspend and hibernate really solve this better (I don't even feel the need for session saving now that I never reboot). Another solution to the problem of restarting all needed apps on the right workspace on start has been discussed several times: have a way to associate apps to a workspace so that they start on it. This would fix most of the problem, especially if you can mark an app for automatic startup on login. An extension implementing static workspaces wouldn't be so bad: indeed, only relatively advanced users would find it, but only this kind of people need static workspaces. Discovering an option would be as hard: the Shell has no settings dialog, so this would end up in gnome-tweak-tool - as obscure as installing an extension from the website that will be released soon. Leaving it up to the designers, but I think this will be a WONTFIX...
(In reply to comment #2) > There are several issues in this report. The workspace isolation thing (bug > 650289) can be implemented while keeping dynamic workspaces, and vice-versa. > Another problem is restarting all apps on login: this is session management, > which is again different from (though complementary to) static workspaces; > suspend and hibernate really solve this better (I don't even feel the need for > session saving now that I never reboot). Hi, Thank you for responding. To me, session management their save are not the level of the kernel (suspend and hibernate), this is the role of gnome-shell. The computer may crash or may not support the suspend and hibernate as is the case for one of the participant to discuss the mailling list. Regards.
(In reply to comment #3) > To me, session management their save are not the level of the kernel (suspend > and hibernate), this is the role of gnome-shell. Sorry, but to us, it is. ;-) More seriously, session saving has never gained much traction and wasn't supported very well since something like GNOME 2.26. OTC, suspend and hibernate work perfectly by design when they work at all. The Shell is designed in part around the idea that you don't need to turn the machine completely off, and I can tell you this works very well (no need to restart any apps for weeks). > The computer may crash or may not support the suspend and hibernate as is the > case for one of the participant to discuss the mailling list. Indeed, sometimes it crashes, but it's more and more stable. When this happens, report bugs, and the fact that GNOME 3 uses it extensively is an incentive for developers to fix theses bugs. Also, suspend and hibernate are supported everywhere, not only on laptops. So, be warned, session management isn't something used by many people (users and developers), so it's not going to work very well anyway. And it's not a major goal of the UI.
*** Bug 664378 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > (In reply to comment #3) > > To me, session management their save are not the level of the kernel (suspend > > and hibernate), this is the role of gnome-shell. > Sorry, but to us, it is. ;-) > > More seriously, session saving has never gained much traction and wasn't > supported very well since something like GNOME 2.26. OTC, suspend and hibernate > work perfectly by design when they work at all. The Shell is designed in part > around the idea that you don't need to turn the machine completely off, and I > can tell you this works very well (no need to restart any apps for weeks). Hi, Another case where the backup sessions is the role of Gnome and can not be delegated to the kernel, it is in companies or universities with a network of workstations and where the "home" directory is mounted via NFS on a server. You can not suspend or hibernate workstation or server. Regards.
Part of the problem is that some users prefer to keep their apps and workspaces in a fixed order, so that they may get used to it and navigate their current activities more easily. This was possible with static workspaces simply by moving the applications to the desired positions or even by setting them to automatically open there. With dynamic workspaces, it is not so clear how one would specify the workspace that a given group of apps would use (maybe one could "bundle" apps so that they are launched together in the current workspace?). Regarding this bug, I wonder if it could be alleviated by allowing the user to reorder the workspaces from the overview with a simple drag-n-drop. It would not be automatic as the reporter requested, but it would make manipulating the current activities a bit easier.
(In reply to comment #7) > Regarding this bug, I wonder if it could be alleviated by allowing the user to > reorder the workspaces from the overview with a simple drag-n-drop. See bug 646409 for that.
By now we actually have a 'dynamic-workspaces' setting in org.gnome.mutter/org.gnome.shell.overrides, closing.