On Wed, 2003-03-19 at 18:09, Havoc Pennington wrote: > On Wed, Mar 19, 2003 at 05:21:48PM -0500, Ettore Perazzoli wrote: > > No, this is wrong. "Quit" involves the idea of an application, not of a > > process. "Quit" means "quit the application", not "quit the process". > > In most cases it's the same thing, but the user doesn't care. He just > > wants to quit the application -- i.e. "Evolution" vs. > > "/usr/bin/evolution". > > What do you mean by "the application"? > > I agree we have such a concept, but it isn't clear to me that the > concept of application that we have is a thing that can be started and > stopped (or quit, or switched to). I don't have any object on the > screen that represents "the application," that can be operated on. Well you have the application menu, which starts the application. It is also true, though, that the situation is blurry after you launch it. There is no object on the screen that tells you that the application is running (besides the items in the window list -- which are per-window but not per-app), sometimes apps have one instance per document and sometimes they have one instance for all the documents, etc. But this is a flaw in the UI, it doesn't mean that we don't have the concept. > What would it mean to "start gnome-terminal the application" vs. > "open a gnome-terminal window"? Does that mean anything? In the current situation, gnome-terminal works in a document-centric-y way, so "starting" or "quitting" the app doesn't make sense. On the other hand, the terminal could work as an application, like Terminal does on OS X. In that case it would make sense; the terminal windows would be part of one single app, Quit would close all the windows, Close would close the current window but not quit the app, etc. > My idea of an application is something like "a kind of window" or > "functionality provider" - a kind of window to use to view/edit a > particular file, a kind of window that has separate Preferences, a > kind of window that's available when you install a particular piece of > software. This is not a strict enough definition of an application though. Windows can behave in different ways depending on what the programmer wants them to do. The real issue is, we don't have a clear model for apps vs. windows vs. documents in GNOME, we basically leave it up to the programmer to do something sensible (and often s/he doesn't ;-)). That's why we have programs that work in an "application" kind of way, programs that work in a "document-driven" kind of way, and programs that are somewhat in between. Given that there is no common model, it's difficult to make rules like "no quit menu". They would not work for all the apps. > I'm using the terminal as an example precisely because it > traditionally has one process per window, and so people expect Quit to > map to the window. ;-) Which shows that understanding Quit has > traditionally involved processes, not kinds of window or > functionality. Traditionally in the Unix world, maybe, but I am pretty sure that the Windows users out there don't think about processes either when they use the "Quit" menu. > There's simply no reason I see why I'd Quit Evolution for example, > other than to exit the Evolution process. If I don't want an Evolution > window, I'd just close it. Why would I Quit instead? It depends on whether you want to close the window or quit the app. :-) > If there's a > reason for Evolution, what makes gnome-terminal or nautilus different? These can both work in an app-like way, with the exception that you never want Nautilus to quit and hence you don't want a Quit menu item there. (Actually, Nautilus already works like that.) > The taskbar grouping, however, is based on group leader, not window > class (in implementation terms). Though I've been thinking of changing > that since it seems to suck. > > GTK maps 1 group leader to 1 process - which means gnome-terminal > --disable-factory affects window grouping. But that is not really > right, and is just because GTK doesn't have the API to fix it. > It should really be 1 group leader per "main window" I think. Yeah but then in that case the program must be designed to handle the various process as one single "app". Otherwise it doesn't make sense. I think the client leader based grouping is fine. On the other hand, it would be useful to have a rule that says that applications should only run one instance of their process, and thus get rid of the possible inconsistency between having multiple processes and having a single process with multiple windows. Of course, then we would have to add support for this to GTK... > If application means "kind of window" that would mean group leader > maps to a document/mainwindow plus transients rather than an > application I suppose. > > I've struggled with the windows vs. applications thing a good bit with > the window list and metacity (there is an archaeological gconf key for > metacity, /apps/metacity/general/application_based=true). I don't > think we're 100% clear on what application based would involve or what > "the application" means in GNOME right now. Metacity and the window > list are all window-based right now in most details. Yeah I agree, right now it's a mess. We should have a better defined model, and enforce it in the development platform. > I'd like to clarify the application vs. window based issue more, it's > a useful discussion. We should start on a higher level there though, > not on the Quit menu item. ;-) I agree 100% -- that's why I brought the issue up. The discussion felt backwards to me. ;-) > One interesting point is that Evolution is kind of different from some > of the other examples (browser, office suite) - it has this concept of > an "Evolution Window" that can be a calendar or todo list or mailbox, > and I can "File->New->Evolution Window" - and there's a way inside the > app of switching between calendar/tasks/mailbox. While one might > expect to have three apps that are integrated but you switch between > and launch them using the normal desktop mechanisms. What is different about it is that you can't define what Evolution is based on the type of window -- but as I already said, that's not a correct way to define what the application is in the first place. -- Ettore
Attachment:
signature.asc
Description: This is a digitally signed message part