[GUI] after the opinion poll
Wed, 12 Feb 2003 09:52:03 +0000
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.
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
> - 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:
> 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.
> 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,
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day