[GUI] after the opinion poll

[Axel Simon]

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