Re: GNUstep on MS Windows

[Richard Frith-Macdonald]

On Sunday, December 7, 2003, at 08:28 AM, Jeff Teunissen wrote:

> Chris Hanson wrote:
>
> [snip]
>
> > (3) Try some experiments with AWT-style peering to get true native
> > widgets rather than lookalikes.
> >
> > I'm moderating my position; I think #2 would be sufficient for many
> > developers, as long as it was done well enough.  I think #3 may be
> > necessary for some developers, but I certainly don't think GNUstep
> > would be useless for commercial developers without it.
>
> Then those developers can use something else. "Native" GUI controls are
> simply out of the question for AppKit, and for obvious reasons.

Well ... the reasons are obvious to you, obvious to me, and probably 
obvious
to all developers who are actually familiar with the gui architecture 
... but
I think they are clearly not obvious to most people who haven't looked 
into
the way the gui abd back libraries work.

I don't think it's worth getting into the technical details which make 
it
obvious ... that would be a long discussions and probably unconvincing 
to
people who haven't looked at and digested the workings of the gui code,
so it's ok to ask people to just accept our word that the gui library 
cannot
reasonably be expected to work with native widgets, but that it can
reasonably be modified to support an interface style which looks like
native widgets.

That doesn't mean that people who want native widget support have to
give up ... they can always write a replacement for the gui library 
using
any bits of the existing code they can ... it just means that it's a 
big job
as (for the native widget approach) they have to write a new gui layer
rather than just a backend layer for the existing gui.

My personal plea is that they should try the approach of getting the 
existing
windows backend fully functional first ... it's a much smaller job, and 
would
provide a reference system against which new development could be
compared.

So ... three stages
1. Get a fully functional backend library in place (NeXT look and feel)
  a) packaged, reliable build
  b) fully working drawing/focus handling etc.
  c) pasteboard and DnD integration
  etc.
2. Add windows interface styles to the gui ... to emulate look etc.
  a) simple drawing updates
  b) menu handling etc
3. If the result is viewed as not good enough ... build an alternative
  gui library using windows widgets directly ... no need to have the
  gui/back separation for this and a lot of the experience from stages
  1 and 2 would be relevant (as well as some of the code).