Hello Gnome, (This is a bit long. Summary: Combine good bits of Gnome and Android application models.)
I know there has already been a lot of discussion around the new style of Gnome applications, with the maximised by default windows and all that, but I want to suggest a different way of thinking about the issue. Here's the history as I see it: 1. Past shells have taken no interest in what the user is trying to achieve - their intent. Instead they provided a heap of tools (window lists, application switchers, virtual desktops, etc) and the user just made whatever use they wanted of these. 2. This was ok for users with only one intent (call it "use computer",) i.e. the people who often only have one application running, and whose projects are rarely more than a couple of files. The only real problem for these people was in the initial learning curve: for example, learning the difference between a file and that same file open in an application. 3. For advanced users, with many intents ("personal stuff", "media", "work stuff", "projectx", "projecty"...) , it was manageable but imperfect: some applications provided profile support, some didn't; the shell wouldn't know how to open a file in the right app instance anyway, or which browser instance a link was meant for, and so on. Each user developed their own system for separating their concerns, based on whatever their shell and apps happened to support. 4. Then Android et al. arrived, with the principle that the user _must_ only have one intent. This simplified model removed the learning curve: there was no longer a difference between a file and the app that displayed it, or an app and an instance of it. It also made it impossible to divide web browsing between personal and work; prevented using the same tool with different settings for different tasks; discouraged using multiple applications together; and generally made the user reliant on app developers anticipating their exact needs. I worry a little that Gnome is drifting too far towards the Android mode. The idea that a "tool" and "task" are interchangeable makes no sense to me: My intents are not 1:1 aligned with the tools I use, so I will always need to combine tools. This means lots of running apps, lots of visible windows, lots of terminals, and lots of switching. I think it may be possible to reach a compromise - bring more facilities to application developers to help them make standardised applications, (and so let them hand off common tasks to the system,) while not removing too many possibilities for the user. This is the briefest possible outline of my idea: 1. Make the idea of "intent" explicit in the shell. An intent is a set of application instances and application profiles, a history of actions, a bunch of files, and anything else required to create a loose boundary around some part of the user's world. 2. Give each user a default intent, and leave them to discover they can have more when they are ready. While "intent" makes sense logically, it's a rather cumbersome expression, so I propose referring to them as custom activities. The "Activities" button in the shell could then be re-purposed, with the current view relating to the default activity, and more controls being added to create and manage custom activities. Most of the UI would be unchanged - starting an app or choosing a virtual desktop is applicable in any activity. Required changes would include adding controls to change focused activity, and to see what customisations exist in the current activitity; an example optional change would be to highlight which current windows are associated with the activity. Some users will never need to know about custom activities, they will just get a simple, Android-esque shell, where every time they click the browser icon they get their single browser instance, and their music collection is the same thing as their music player. The rest of us get that same thing, multiplied as many times as we want it. We get the advantages of a rigid application model, such as automatic suspending of applications (done with work for the day? just close that activity, it can be exactly restored tomorrow,) but infinitely many times. The job of the shell would be to help the user attach things to their activities. Application instances could be attached, perhaps by dragging their icon into a group on the dash. Files in "projectx"'s file browser instance will open in the "projectx" text editor instance, and those files can be marked as related to "projectx", and their use logged as such to help the user find them later. Of course the shell won't always get this right, so there's no question that the user must have final say. It should be possible for the user to examine their custom activities, assign files to them, control which applications have custom settings within the intent, and so on. I think this could work, but maybe it would be impractical to implement, or too complex to use. Regardless, the important thing I want to say is that for some people an application is not a task, or a document or a file. Lots of these things need to be orchestrated to achieve complex intents, and if the shell can't do it automatically, then we need to factor in a good manual path to let advanced users manage themselves. Thanks, -- Phil Housley _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list