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

[Richard Dale]

On Fri, 17 Aug 2001, 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 ?
Yes, it makes perfect sense to me - I've been working on Qt/KDE Objective-C
bindings for some time now. Please find attached the code for the Qt Scribble
example in Objective-C. Slots and signals are like a cross between
actions/outlets and NSNotificationCenter. You could use slots/signals for the
gui, but NSNotificationCenter in the back end.

//      Connecting an Objective-C signal to an Objective-C slot:
        [QObject  connect: self signal: @"colorChanged:"
                       receiver: _scribblearea slot: @"setColor:" ];
...
        
//      Emitting a signal:
        [self emit: @"colorChanged:" value: [Qt black]];

//      Adding a menu item connected to the C++ signal 'quit()':
        [_filemenu insertTextItem: @"&Quit" receiver: [QApplication qApp] slot: 
@"quit()"];

If the type signature in the connect statement looks like C++ (eg 'quit()'), it
connects the Objective-C target slot to the underlying peer C++ instance's
signal. If the type signature looks like an Objective-C selector, the connect
is to an Objective-C signal (eg 'setColor:').

// Event handling and painting example:
- (void) resizeEvent: (QResizeEvent *) event
{
        QPixmap * save = [[_buffer copy] autorelease];
        [_buffer resize: [event size]];
        [_buffer fill: [Qt white]];
        [QPaintDevice bitBlt: _buffer dx: 0 dy: 0 source: save];

// The top level:
int main(int argc, char *argv[])
{
        QApplication * myapp = [[QApplication alloc] initWithArgc: argc argv: 
argv];
        
        QWidget * mywidget = [[ScribbleWindow alloc] init];
        [mywidget setGeometry: 50 y: 500 w: 400 h: 400];

        [myapp setMainWidget: mywidget];
        [mywidget show];

        return [myapp exec];
}

To use Distributed Objects, I think a QTimer timer task would need to be started
to periodically poll the NSRunLoop - I haven't done that yet. It would need to
be added to [QApplication: initWithArgc:argv:], where the autorelease pool gets
initialised.

Qt's equivalent of InterfaceBuilder is Qt Designer - it generates xml based .ui
files which are compiled by a tool called 'uic' to generate C++. It
should b possible to patch the uic to generate Objective-C (I've done the same
for Java).

The bindings will be part of KDE project, I haven't checked them in yet. I can
send the current version for Qt 2.3.0 as 2 800k (Qt C and Qt Objective-C) mail
attachments to anyone interested. The main problem with interfacing C++ libs to
Objective-C is that you can't currently call C++ directly for Objective-C, and
so you have to write C bindings as well as Objective-C ones. It will be a lot
better when the Objective-C++ compiler is widely available.

 -- Richard

main.m
Description: Text Data