[GUI] ANNOUNCE: Specification for abstract user interface for Windows, GNOME and Aqua

[Wolfgang Thaller]

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