
--- Axel Simon
Hi all,
I summarized everything that was said on this email list. I put the result on the web and would like to ask everybody to review it and correct what I got wrong:
After all, are we ready to specify any kind of low level API? I propose to specify just some set of modules with corresponding functions and data types, while the implementation will leave unspecified. That will allow to implement API with various backends: - wxWindows - GTK - WIN32 - Aqua Maybe the wxWindows backed will be good starting point for the first working prototype. I still prefer native WIN32 and GTK backends but this is just my own preference. Regardless of my own preference I think that if we keep API definition independent of wxWindows or some other backend, that will make possible for voluntiers (like me) to implement API for their prefered backends (WIN32, GTK). I found following key stones: - the implementation for scrolled windows should follow design of GtkScrolledWindow instead of desing of WIN32 which is adopted in ObjectIO. It is interesting that .NET WindowsForms also uses approach similar to GTK. The GTK approach is a litle bit high level and it is more easy to emulate on various platforms. - the menu bar under MAC is attached to application while under WIN32 and GTK it is attached to window. I was already posted some proposals in my previos mail: http://haskell.cs.yale.edu/pipermail/gui/2003-January/000106.html Wolfgang Thaller wrote that "Basically, that should work" but also mention that there are also other differences like "Quit", "About" and probably some other menu commands. See: http://haskell.cs.yale.edu/pipermail/gui/2003-January/000107.html I tried to implement menu bar in Port, following my own proposal and found that this works. In addition to the user specified menu bar the library automaticaly maintain Windows menu for MDI interface. I think that it also can maintain "Quit" and "About" menus. The menu commands should be placed in its prefered places: WIN32 and GTK: "Quit" should be renamed to "Exit" and should be placed in "File" menu. "About" should be in "Help" menu. Aqua: "Quit" and "About" should be placed in "Finder" menu. In both cases the "Quit" will automaticaly close window/application and the "About" should call user specified function which will display About dialog. If the user doesn't specify his/her own function then the library should display system defined About dialog,which will display the application name and the short application description, which need to be specified in the library inialization phase. There are also some reasons to standardize "New file" and "Open file" commands. - The drawing primitives should use graphics context as it is proposed from Axel. This differs from the implementation used in ObjectIO and Port. Best regards, Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com