> Mind-boggling: yes. Lunatic: not necessarily :) Yay!
> > If I'm understanding you properly, the user should have no concept of > services or processes. There is a single list of all applications, > whether they are running with a window, running as a service, or not > running at all. > When the user clicks on an application which is not running, or > running as a service, then the control window for that application > opens on top. When all of an application's windows are closed, then > the process closes (as long as no services are running). If a service > is running as well, it is responsible for garbage-collecting itself > when it is no longer doing anything (ie when rhythmbox is no longer > playing music). When a service process exits like this, the UI > shouldn't change at all - the user shouldn't even know. Indeed! I'm glad to know I made sense :) I think declaring a model for interaction with applications and windows, like this (or this, even; that would make _me_ happy at least) would go a long way since we really don't have one right now. I want to think of a window as a view. Now Close would mean "disappear that view", Minimize means "make that view really small" and Maximize means "make that view really big," and importantly that meaning should never, ever vary. The resource being viewed is just there. > > The only question I have right now about this model is the action > which occurs when an app with a window already open is clicked on in > the list. In the current windowing model, you can focus the existing > window (via the task bar) or open a second window (via the menu). With > the integrated application list, how do we nicely handle both of these > use cases? > > Cheers, > Evan This is something I think gnome-shell handles pretty well. If you click an application with open windows, it knows, so it focuses those windows on its own. Right clicking gives you an option to create a new window. (Personally, I would like a little + button to one corner of the icon so it isn't a secondary operation). As I understand it, upcoming stuff will make that kind of behaviour slightly adjustable per application. Existing applications use libunique, and I think it's an okay approach. So, right now if I have Rhythmbox running in the background and I want to choose a new playlist, I can head to Applications›Rhythmbox and the existing window is instantly focused. It's just like opening a fresh instance, as if Rhythmbox's main window really is in a different process from what plays the music (like the Telepathy stack). However, this particular job is a loopy mess under the hood! * Application sets up with DBus for the single purpose of watching for new instances trying to launch. * New instance of application is opened, sees the old one, does something. Hopefully it tells the existing instance that the user has declared interest in using it, but we never really know. * In the ideal case, the existing instance of the application either creates a new window in the current workspace (good!) or raises the old window. It's that latter case which breaks my heart: if you aren't in the same workspace as the old window, it never shows up. It sets the Urgent window hint and a tiny little item in the window list appears. Now, in the ideal case, the user journeys to the other side of his 37" screen, clicks that OTHER thing for no apparent reason, and finally sees his window... but he's sent to the wrong workspace! Gnome Shell makes that mess completely the window manager's responsibility (and the window manager is quite comfortable managing windows), so there is no likely point of failure. Not ideal, though, since it doesn't cover everything (at least not yet). Maybe we just really need a more reliable way for applications to control their own windows. (Sorry, I just realized I've been throwing around the words "application", "process" and "resource" almost interchangeably. Hopefully this isn't completely nonsense at this point). Alas, there is still the issue that, if you had the Rhythmbox controller window open and focused somewhere and it pretends to open another by moving that old window to view, your old window is no longer where you left it… As for some apps supporting multiple views, err, windows, I think it makes sense: you can only have one view per _resource_, so for Abiword that resource is a single document and, if I recall correctly, it correctly enforces that policy. Most things do. Thankfully for us, it's just really hard for an application to manage multiple windows that refer to the same thing. And it (should be) pointless, too. Every time you choose Rhythmbox from the Applications menu, you're opening a controller for a single resource: the music service (which doesn't actually exist, but makes a fine imaginary construct). So, its behaviour of only allowing one controller is quite consistent! Oh, my tea is ready! Bye :) Dylan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
