discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Aurelien
Subject: Re: JXTA for ObjC (was: Re: a simple program)
Date: Fri, 17 Aug 2001 16:23:07 +0200

Le vendredi 17 août 2001, à 02:41, Richard Frith-Macdonald a écrit :

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.

I'm not sure I understand this very well. The front-end thus calls the back-end's drawing routine and the back-end makes callbacks on the front-end's event handling routines ? So the back-end is just an abstract layer to the native OS ? I mean, do you have routines like drawRect (), fillOval, and the like in the back-end, which in turn call native routines to do it ?

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.

I wasn't talking GTK, but QT (but maybe it's roughly the same thing). I was under the impression that the most unstable part of GNUstep's work was the AppKit. I can understand that a not-for-profit effort trying to create an entire GUI library with support for PostScript is a huge task and could still take a while before it reaches maturity. My idea is, provided we set aside the great benefit of having PostScript everywhere, the use of QT would make GNUstep more readily useable. By saying <quote>[...] It would gain a certain degree of stability [...]</quote>, are you acknowledging these assumptions ?

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.

OK, thus we would have exactly the same application on each and every platform (what you wish) ?

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 this was done with QT, which also has the ability to set the interface style, this could be done once for all platforms. Pardon me if I'm wrong, this wouldn't require to write anything for the back-end; this again is already being done by QT.

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.

Yes, but that would force the developer to write a GUI/platform.

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

Yes, but you cannot just bypass the fact that users are reluctant to non-native l&f. I myself tend to consider a non-native application as being amateurish, though I admit this is 100% irrational. Now, talking personal tastes, I never had the chance to use a NeXT computer, but from the screenshots you see on gnustep.org, pardon me, but it's making me sick. In particular, the techy dark gray/black option is frightening, really. But, again, when I'll have something compiled on my Linux box, and used it a bit, maybe I'll change my mind...

BTW, thanks for the thread-safe version of the "simple program". I'll try to put it to work this we, and I'll let you know for sure if it works :-)

Regards,

Aurélien
reply via email to

[Prev in Thread] Current Thread [Next in Thread]