Re: GNUstep on MS Windows

[Nicola Pero]

> > [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 ...

It's definitely out of question to have the AppKit work on top of alien
widgets.  It makes no sense and I agree with you.

But there is another option open -- you could implement a specified subset
of the AppKit API using alien widgets.

Let's call this library (a completely new library different from
gnustep-gui) a 'restricted Windows native GUI'.  It would implement a
subset of the AppKit API - maybe you'd have a NSButton with a setTarget:,
setAction:, setType:, setTitle: and a few other methods; but most internal
methods would be missing (eg you couldn't override drawRect: or
trackMouse: or whatever the names of those methods, they might not be
there at all).

Yes, it would mean you can no longer subclass a NSButton.  It would mean
you can not override drawRect: of a button.  It would mean part of the
NSButton methods/API are not available, it would mean if you start digging
a bit too much in the OpenStep AppKit API you'd get in troubles.

But if the resulting widget implements enough of the basic methods and API
(-initWith:, -sizeToFit:, -setTitle; etc), Renaissance could still use it
to create the widget from a <button> tag ...

Then, if you create your GUI using Renaissance, a <button> tag could
generate a native GNUstep NSButton on GNUstep, a 'native GNUstep NSButton
emulating Windows button' on GNustep on Windows, and a 'native Windows
button' when using this 'restricted WIndows native GUI' on Windows.

That might actually work very well for simple GUIs which are 99% of the
GUIs.  The hard part is when you actually do need to subclass a GUI object
to implement something specific to your application.  I suppose the
'restricted Windows' thing could at some point implement a reasonably
general NSView where you can draw in it, or such stuff.

But if you ignore custom subclasses and only worry about making standard
widgets available, it shouldn't be very difficult to implement this thing.  
Not very difficult, but might be tedious and long -- you'd have to wrap
native windows widgets in an API which superficially resembles the
OpenStep AppKit API - the resemblance has to be enough deep that soemthing
like Renaissance can create widgets using the same calls it does on
gnustep-gui, but not too deep as to make the thing possible.

I don't volunteer though -- lack of time -- just wanted to suggest the
option.