--- Axel Simon wrote:

http://www.cs.kent.ac.uk/people/staff/as49/rationale.pdf

To summarize, I make the following proposal:

- have two application setups, document centered and control oriented - have toolbars, each toolbar item correspond to a menu item - have toolboxes which lets the user choose between, well, tools

Very useful reference. It is more detailed and contains some points which I leave out. I think that the controled SDI (CSDI) interface can be added to HToolkit without modification of the high-level API of the library. For toolbars I already have some ideas. In the time being I work against time on the toolbars for Windows. I think that we need a common abstraction for toolbar items and for menu items. The idea is that the toolbar and menu item which are related to one and the same command must share the same bitmap, title and tooltip. Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Hello Everyone! Those documents you posted are both great work, IMHO. Just some fine points; Axel Simon wrote:

- have toolbars, each toolbar item correspond to a menu item - have toolboxes which lets the user choose between, well, tools

Perfect.

- have two application setups, document centered and control oriented

Yes, that's a good starting point. Should we postpone the following more advanced features to later versions of the CGA? *) multiple document types For different document types, most non-mac people will probably want different menus rather than just disabling menu items. On the mac, this wouldn't be the right thing to do, although there _have_ been respected Mac OS programs that did that to a limited extent. *) multi-window documents Some applications open a separate window for editing objects which are part of one document (imagine a word-processing app that opens a separate formula editor window when you double-click a formula). *) Control-oriented applications and menu bars: Some control-oriented applications have menu bars --- a MP3 player application might have one, for example. Others consist of one or more dialog windows and no application-specific menu commands. Do Win32 and GNOME users expect the main dialog window to have a menu bar with the standard commands (About, Quit, Edit commands), and nothing else? Mac users certainly do, but I've seen many small Windows & Unix utility apps display just a dialog without any menus. And now about Krasimir's document: *) The Services menu in Aqua is filled by the OS. It's contents are defined by other applications installed on the system. For example, Apple's Mail application provides "Send Selection" and "Send Mail To" entries that work on the currently selected text in any application. In order to support this, an application has to provide information about what is currenlty selected; for the standard text widgets, this can be handled transparently by the backend. For other things (the mechanism isn't limited to text), it's probably too platform-specific to bother. *) Open Dialogs on Mac OS allow multiple selection (so you can open several files at once). *) Mac application have to specify the document types they support (together with their associated ic ons, extensions and traditional Mac OS file type codes), in a separate "property list" file that is included within the application package. It cannot be specified at runtime because it has to be available before the application is ever run. *) Apart from the use of file extensions, Mac OS also supports four-character type codes ("HFS file types"). Apple currently recommends using both, although many programs only use one of the two methods. In the open dialog box, a text editor would need to display *) all files whose HFS file type is 'TEXT' and *) all files whose HFS file type is unspecified and whose name ends with ".txt". For application-specific file formats this is simpler, as it will be sufficient to use just file extensions. Also, Mac OS doesn't usually display a "Show all files" option (in most cases, they don't make sense, after all). Some applications (plain text editors, hex editors, etc.), provide one, so maybe add another Bool parameter for that. I've seen at least one Java application that was next to unusable on the mac because it expected users to choose "*.*" from a file type menu that didn't exist in the mac version... *) Opening files via drag&drop: In order to open a file on the mac, you drag it to the Application's icon, not to one of it's window. Dragging something to a window means: insert it _into_ that document (if possible), not open a new document. Whether or not it is possible to drag a particular file to the application icon is determined by the list of supported document types that I mentioned earlier. *) The "Zoom" command (Window menu) and the Zoom (+) button in the window title bar (both do the same). Apart from un-minimizing a window, zoom also switches a window between a user defined size and position and an "optimal" application defined size and position. This is similar to the maximize button on other platforms, but it's not the same. The application-defined size needn't be the full screen; for example, for word-processing apps, it shouldn't be wider than the documen'ts page width, and for image processing apps it shouldn't be larger than the image. Zooming to full-screen is a good choice, but seldom perfect. For this to work perfectly, the optimal size has to be calculated by the application. It's probably OK to ignore this in a first version and add it as an optional feature later. Cheers, Wolfgang