Hello Wolfgang!
First of all thanks for your constructive criticism.
--- Wolfgang Thaller
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.
Not obligatory. Maybe this should be optional.
And now about Krasimir's document: [..] *) Open Dialogs on Mac OS allow multiple selection (so you can open several files at once).
For that reason in HToolkit there are two functions: runInputFileDialog and runInputFilesDialog. The first allows selection of just one file while the second allows selection of multiple files. Allowing multiple selection in the File/Open option should be useful for both Win32 and GNOME ports.
*) 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.
Where I can read more about the content of the "property list" file?
*) Apart from the use of file extensions, Mac OS also supports four-character type codes ("HFS file types").
For that reason GNOME uses "mime types". In my proposal the mime type is accessible from dtMimeType field in the DocumentTemplate record. One solution is to add dtContentType field which will contain HFS file type.
*) 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 same situation is when the Windows user double click a file from the Explorer. The association between the file type and the application is determined from small database in the Windows Registry. Many applications fills the records for their supported file types when they are started for the first time. I think that the information collected in the DocumentTemplate records is enough to fill the types database. For that aim the library should export function like: registerFileTypes :: IO () The only missing part is that to fill the database we need the document name. For example for MP3 files the usual name is MP3File, for GIF - GIFFile ... The document name can be constructed from the dtContentType field (announced above) and the "File" word. Under Mac the registerFileTypes function can generate the "property list" file. Cheers, Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com