I'm always in a hurry (as often young people do ;)). Here are relevant quotes (relevant against latest specs) from the kde HIG. ------------------------ Application model in KDE ------------------------ The kde2 HIG, wich should be also valid for kde3, is located at http://developer.kde.org/documentation/standards/kde/style/basics/index.html * The title of new windows wich are still not associated to a document is unspecified in the HIG. * The title of document windows is "document name - application name". Showing or not the file extension and the document path is unspecified. * The title of the control window of "controlled SDI" (see later) application should be "- Control". It is unclear (but I guess it is so) if the title should be "Control - application name". * There are three models for document-centric applications in kde: pure SDI, cooperative SDI and controlled SDI. In the first model, the application might also create new windows (with an entry in the file menu), but each windows should behave as a separate application. The second model extends pure SDI with an exception: all the windows share common attributes (the configuration of the application) and changing an attribute from a windows should act on all the open windows. In pure SDI this is forbidden. The third model is for applications like image viewers, where the number of open windows could be higher than the number of available windows. In that case there can be a main windows wich controls all the other. I guess this is mainly to justify office suites control windows or a gimp-like design. A consideration about SDI/MDI: even if the kde HIG explicitly deprecate the use of any kind of MDI model, in fact there are application wich are just more comfortable with that model (think about tabbed browsing in a web browser), so it should not be denied to create tabbed or paned windows in kde. OTOH, it should be possible to adopt what kde calls "cooperative SDI"(see later) in gnome, even if the default for multiple documents is a tabbed view. This is the case when you write e.g. a web browser in gnome: you can open a document in another window, and both windows should behave as if they were separate applications, but they should share the configuration in any moment. Besides, the KDE SDI model should behave as if any window had a separate unix process, even if all windows might have been internally created by the same process. In that case, I think that there should be no "Quit the whole application" button. This is the case in konqueror. Should it also be the case in an eventual "cooperative SDI" for gnome? I think so. ------------------------------------- Pure SDI in KDE / quotes from the HIG ------------------------------------- "If a Pure SDI application is iconified, its document window and any other windows it has opened, such as help windows, dialogs, toolbars and so on, should be iconified with it. The window manager should present just one icon, which should bring back all the windows when activated." Note that this does NOT mean that iconifying a document window should iconify ALL document windows, because any document window should behave LIKE A SEPARATE APPLICATION. "A drag and drop operation into a document window should perform an Open on the dragged document in that window." This means that kde's idea of SDI is completely different from that of Aqua. IMPORTANT: Does this mean that kde really uses only a form of MDI in wich each document is on a separate window? Is this definition enough to forget about "controlled SDI" and "cooperative SDI" in CGA and just implement all kde's application with the MDI model, demanding to the programmer the task of deciding if it is "cooperative" or "pure"? "Whenever a Pure SDI application is started, it should, if possible, check for an already running copy of itself. If such a copy is found, it should be that copy which performs a New action, thus making a new application appear. This guideline is so that large programs, such a Wordprocessors, don't simply run in multiple copies of themselves and hog all the user's memory." "There should be one instance of an extra window, such as a toolbar, per window, as required by the user. Two application windows must not be allowed to share one toolbar, even if this is technically possible because of the way the application has been implemented." "under the SDI mode, applications are separate; and changing something in one of them may not in any way affect what happens in another". This is the main distinction between cooperative and pure SDI. --------------- Cooperative SDI --------------- "Each window still contains exactly one document, and each document still represents one instance of the application. There is still a menu on each window, and the menu items work as described for the Pure SDI model. However, each application window is aware of the other windows that are running the same application, and this awareness may be utilised by the application. An application may have another menu on its menubar, labelled 'Windows'. If present, this should be the rightmost entry (except for Help). The menu will contain a list of the other documents currently open in other windows; selecting one from the list will raise the appropriate window. The Windows menu may also contain a Close all option. This option should be located at the bottom and be separated from the items above it. It should close all the listed documents and their windows." -------------- Controlled SDI -------------- "suppose an application is launched with a command like "Kapp *.jpg", and there are 2000 JPEG files in the working directory. Under Pure SDI or Co-operating SDI, where one document has one window, 2000 windows would open. This would be a bad thing. The solution to this problem is to have some sort of controlling window, often containing a list of the files which are open and ready for use. New document windows are created in order to work with these files as required." "It is vitally important to understand that the controlling window does not contain or in any way restrict the movement of the document windows. This is not an MDI interface; it is an SDI interface that uses a controlling mechanism." "The control window should have a menu laid out according to the normal guidelines. This menu will probably not be the same as the menus on the document windows. The File menu will have a New entry, but no Open. The Quit option of the control window closes all the document windows (after any necessary save prompts) and exits the entire application. " "The Windows menu entries introduced in the Co-operating SDI model, should be available on the control window File menu as well as the document windows. Document windows should have the same menu items that they would have in the Co-operating SDI model. The contents of the control window are not laid down by these guidelines" "The top entry in the Window menu of each window should be the control window" Bye Vincenzo