Re: New Ada portable GUI Library?

[Martin Krischik <krischik@users.sourceforge.net>]

Ludovic Brenta schrieb:

> Martin Krischik wrote:
>> Ludovic Brenta schrieb:
>>
>>> Martin Krischik wrote:
>>>> I have another suggestion: A GUI Library based on OpenStep [1].
>>> [...]
>>>> [1] http://en.wikipedia.org/wiki/OpenStep
>>> Do you mean a reimplementation of the OpenStep specification in Ada,
>>> or an Ada binding to GNUstep (http://www.gnustep.org) ?
>> The later. AFAIK GNUStep uses only a small message based dynamically
>> typed API with a plain C specification. Qt and Gtk+ use huge OO API's in
>> C++ or some kind of strange OO-C.
>>
>> To make use of that API easier special languages like Objective-C and
>> Objective-C++ are used. Those languages can be implemented by a
>> preprocessor (currently they are not) so I believe creating an
>> Objective-Ada preprocessor should be possible - especially since Ada
>> does not use '[' ']' and '@' ;-).
> 
> An "Objective-Ada" preprocessor is unnecessary because Ada is already
> object-oriented, and now even has interfaces similar to Objective-C's
> protocols. Therefore, one would only need a binding generator that
> would produce Ada specifications with pragma Import statements from
> Objective-C specifications. Of course, such a binding generator would
> have to know how the particular Objective-C compiler mangles names.

Same for C++ - still they created Objective-C++. Read this Article to
see why a static mapping won't make any sense:

http://objc.toodarkpark.net/coreobjc.html#1522

Almost all the work is done by just one function: objc_msgSend. Mind
you, just saw a little problem here. objc_msgSend is the most important
function from OpenStep/GNUStep and it's a vararg function :-| .

> The stumbling blocks would be to implement Objective-C's reflection,
> dynamic typing and garbage collection in Ada. In particular,
> reflection and dynamic typing are alien to Ada's philosophy.

You don't - you use the objc runtime which should provide all those via
 plain C functions.

> 
>> We would not be the first: Google-ing shows that Objective-TCL [1],
>> Objective-Perl [2] already exists and Objective-Cobol and
>> Objective-Fortran are rumoured [3] - even talk about Objective-Ada isn't
>> new [3].
> 
> That was before Ada 95 added tagged types.

:-)

>> The advantage is that once we have an preprocessor the hole library
>> becomes available. That's unlike Gtk or Qt where we have to write a
>> separate binding for each class we want to use and where - forever - we
>> will be hobbling behind.
> 
> I don't think the preprocessor you speak of would solve anything; the
> binding generator might but beware of the stumbling blocks I
> mentioned.

But it will solve the biggest problem: the endless amount of methods. A
GUI lib easily got 100 classes. Defining 100 classes is doable - but
each class will have what about 20 methods. Yes 20 is realistic for GUI
lib. That would be 2000 pragma imports - endless work.

But here comes the beauty of OpenStep: all method calls are done by
objc_msgSend.

The Objective-XXX call:

[anObject setOrigin:0.0 :0.0];

becomes:

objc_msgSend (anObject, "setOrigin", 0.0, 0.0);

And yes: that is a string. And no: it's not as slow as you think - there
are caches employed to speed things up.

>>> The latter
>>> would require both the Ada and Objective-C runtime libraries...
>> Indeed - but that is not different from Gtk+ and Qt approach. And bare
>> metal is only feasible for Windows but not for X11.
> 
> OK, Qt requires a C++ runtime like GNUstep requires an Objective-C
> runtime. However, GTK+ only requires the C runtime

That might have been the original idea, but soon they needed Glib2 - to
make things easier. And then a few more: ATK, Cairo, Fontconfig,
FreeType, Pango, Poppler, libPNG, libXML, libiconv, librsvg, pkg-config
as of my last counting:

http://gnuada.sourceforge.net/pmwiki.php/Main/PartnerProjects

Of course, you would not notice in Debian as those libs are all part of
the default installation - but you do on for example Solaris.

> and that's
> intentional: one of the design goals of GTK+ from the onset is to
> facilitate bindings to other languages.

Ahh, "design goals" - Well Gtk+ is full of broken promises.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com