Krasimir, I think I agree to all you said and feel happy (and more confident) that we find a common route. Before we start discussing implementation details, I would like to formulate a Mission Statement which should talk about what we want in terms of - adherence to native look and feel, possibly restricting the common API in its functionality - professional vs. educational API (former) - level of the common API - platforms we want to cover - the process of finding the API - maybe more And of course all these should be motivated from the discussion. After that we should definitely answer those questions you mentioned, I am especially sorry that we didn't even bother to respond to the MDI/SDI/NDI mail you sent. But that's one of the first things to tackle. Axel. On Wed, Feb 12, 2003 at 01:30:44AM -0800, Krasimir Angelov wrote: > 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

On Wed, Feb 12, 2003 at 12:22:44PM +0100, Nick Name wrote:

On Wed, 12 Feb 2003 09:52:03 +0000 Axel Simon wrote:

...

I would like to formulate a Mission Statement which should talk about what we want

Feel free to call it a "requirements analysis" so our work will appear good to software engineers :)

I think Mission Statement is more general since it has to address not only the requirements (what) but also how we are tackling things. We'll see. Axel.