Re: JXTA for ObjC (was: Re: a simple program)

[Richard Frith-Macdonald]

On Friday, August 17, 2001, at 11:27 AM, Aurelien wrote:

> Le vendredi 17 août 2001, à 11:30, Richard Frith-Macdonald a écrit :
>
> > > I would like confirmation on the following assumptions about ObjC:
> > >
> > > - It is possible to make Obj-C GUIs have the look-and-feel of all 
> > > existing platform (perhaps by using QT in the back-end);
> >
> > Of course ... though that would be using the base library, not the gui 
> > (which is written to have the NeXTstep look
> > and feel rather than a native one).
>
> What I'd like to do is dynamically load Obj-C code in the form of an 
> NSBundle. Then the code would pop-up a GUI that would be native to the 
> operating platform. I'm still confuse (despite having read the faq) 
> about the front-end/back-end distinction. Now QT is a cross-platform 
> C++ GUI library. It's the one library that was used to write the KDE 
> desktop on Linux. Their library works on Mac OS X, Linux, Windows, and 
> embedded Linux. Because it is said that the "back-end" engine for 
> GnuStep can make GTK or Win32 calls, I thought that it could also make 
> QT calls... Does this all make sense, or am I totally out of bounds ?

The gui frontend implements the look and feel, the backend handles 
drawing and incoming event processing.

While you can call any old windowing library from ObjC, it does not make 
sense to use something like GTK
from the gui backend (or from the frontend for that matter), as GTK 
operates mostly at the level that the
gui frontend works at.  GTK really imposes it's own look and feel 
(subject to various themes etc) and it's
own way of handling the gui, which would conflict with the 
GNUstep/OpenStep gui API.

So, if you wanted to write a GTK application, you would call the toolkit 
from your ObjC code and would
just not use the GNUstep gui code.  The resulting app would have the GTK 
look and feel, and be just
as horrible to use as other GTK apps :-)  It would gain a certain degree 
of stability and GNUstep
interoperability from an underlying use of the base library, but would 
not look or feel like a GNUstep
app.

Certainly you could use bundles to have various guis for your 
application using any gui you like.

You could also use bundles to write different backends for the GNUstep 
gui, but the frontend would
impose a GNUstep look and feel - the backend would be handling only 
low-level operations.

The frontend has something called NSInterfaceStyle, which can be used to 
change the look and feel,
but it requires you to actually implement the code to handle the new 
look and feel within the frontend
library, so it's not a great mechanism.  If you really want a totally 
different, native, look and feel
it makes more sense to omit the GNUstep gui and work with the native gui 
library directly.

PS. Just in case it's not already apparent ... I prefer to use the 
GNUstep look and feel on every
system rather than use native look and feel.  Even though Apples new 
MacOS-X is very pretty, I still
believe that the NeXTstep gui was (a little) prettier (look)  and (a 
lot) more usable (feel).