Re: GStep GUI Design

[Nicola Pero]

> > My impression is that the opposite is true ... unless exceedingly
> > carefully
> > done, I think that trying it use native widgets is liable to end up with
> > either altering the gui library so it's completely incompatibile with
> > OpenStep
> > and MacOS-X (which is just not acceptable), or making the mapping code
> > that
> > converts from OpenStep to windows so complex that any gains of using the
> > native widgets are hopelessly outweighed by the trickiness of the
> > intermediate
> > code.
> > I'm basing this judgment on the fact that what you appear to be
> > describing
> > sounds much like the original approach that was taken for X, and which
> > proved to be pretty unworkable.  In contrast, porting the current design
> > used by xgps to window should be quite simple.
> 
> The wxWindows class library is a very good example of how it can be done. It 
> not only wraps existing widgets (MOTIF, GTK, Win32, Mac,OS  !) but also 
> prosents an uniform interface for writing portable widgets as well. I 
> strongly believe that a similar implementation is possible for AppKit .

I agree with Richard.

You don't need to implement a full DPS support to make a Windows backend _
xgps does not have full DPS support _ not at all _ just some basic
functions.

You just need to implement some basic functionality - creating windows,
managing events, drawing lines in the window, drawing text in the window,
copying images around, changing cursors _ the gui uses this functionality
to do all the rest.

You would have to implement all this functionality *anyway* because it is
available as part of the public API _ the API gives you functions and
classes to draw lines or text or create windows or paste images or change
cursors _

The way I view this is that in the backend you implement this subset of
the library functionality which is platform-dependent _ all the rest is
built on top of this in a platform independent way _ 

Your solution would result in more backend code to write, because you have
to implement this subset anyway, plus rewriting most widgets using native
widgets _ which will never work completely satisfactorily and it's just
additional work because once you've implemented the platform dependent
subset, the gui can create all widgets on top of this already _

If you are a bit afraid of the complexity of the xgps backend code, I
understand that _ but well writing a Windows backend probably includes
trying to simplify and standardize/rationalize the interface between the
backend and the frontend _ without using native widgets and without
destroying the possibility of using a DPS backend, but trying to
rationalize which basic functions/methods the backend needs to implement
to work.