Re: GStep GUI Design

[V . Krishna Kumar]

On Sunday 02 December 2001 18:15, you wrote:
> On Sunday, December 2, 2001, at 05:53 PM, V.Krishna Kumar wrote:
> > On Sunday 02 December 2001 00:38, you wrote:
> >> Only years later I did get back to GNUstep, which now had a totally
> >> different structure. (In the code as well as in the project
> >> organization) GNUstep had just adopted a new separation between front
> >> end and back end, which allows the later to be very simple. And I most
> >> say that I like this new structure much better than what I did plan to
> >> implement. A MS Window back end based on this would be possible to
> >> write
> >> in a few days. What must be done is write some code to create windows
> >> and the event handler, e.g. as a window function used by these windows.
> >> On top of this you just need a small drawing unit that is able to
> >> handle
> >> simple operations as defined in NSBezierPath.
> >> On the other hand to implement GNUstep based on native MS widget would
> >> look much more consistent with other Window programs. But to do this
> >> you
> >> would have to reimplement most of the code that is already there in the
> >> gui module and you would have to make compromises in the way the
> >> classes
> >> work. It wont be possible to change the basic way those widgets get
> >> drawn by GNUstep means. So a program written for GNUstep running on X
> >> or
> >> for MacOSX that redefines the drawing of widgets won't work the same on
> >> MS Windows.
> >> The netto result is that you will have to implement more and get less
> >> portability. I don't think that the better appearance is worth this. We
> >> should rather invest this extra time to make the whole of GNUstep
> >> themeable.
> >> If you still are interested in writing a MS Windows back end for
> >> GNUstep
> >> I would be glad if you could help you with that, given I find some time
> >> for it.
> >>
> >> Fred
> >
> > The pros easily outweigh the cons.
>
> 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 .


> There is an huge number of widgets
>
> > implemented in M$ Windows. So why dont we just use them ?
>
> Because they don't map to the OpenStep design, so using them would make
> your
> code non-portable ... which obviates a major feature of the OpenStep
> system.

I dont agree with you on this. The OpenStep (as I understand it) is very 
flexible and very well thought out. So with a few changes, can be easily 
mapped to almost all modern windowing systems. My reasoning is this:
the most vital component in OpenStep is DPS. That's missing in GNUStep.
so why dont we alter the design so that it maps readily to what we have ? 

> In general, it should be possible for apps which want to be non-portable
> to
> drop back to using native code directly, but I believe that the GNUstep
> gui
> implementation should be consistent across all platforms, and should be
> source code compatible with MacOS-X and (as far as possible) OpenStep.
Adherence to the spec is my aim as well.

> Also, on a purely aesthetic basis, I'd prefer it if GNUstep windows apps
> had the NeXT look and feel rather than a native look ... but I'm aware
> that
> that is a highly contentious view, and I'm not about to object to
> anything
> just because of that.

Well, I always thought that the native M$ look and feel is a modified 
version of NeXT's  (I've never seen a NeXT or a Mac. only the screenshots).

> > One more thing: is the current gstep-gui implementation thread safe ?
>
> No - that needs work.
Thread safe event handling is a very important asset. Anybody working on this 
?

On to a completely different topic:

There are a lot of proposals on the mailing list. I would like to throw a few 
as well:

1)  A series of books on GNUstep. something like "GNUStep Developer Series" 
PART1:  Foundation libs
PART2: AppKit 
... etc.

2) Porting GNUstep to the QNX RTOS (freely available for non-commercial use).

3) A CURSES based version of AppKit (something like the famous TurboVision 
library). This in conjunction with the database library can be used to build 
data entry applications that work on less sophisticated boxes with a small 
footprint. 

Any takers ?

-cheers,
Krish