Re: New Ada portable GUI Library?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Martin Krischik wrote:
> 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

I agree that a static mapping doesn't make sense; that's why I was
thinking about a binding generator. A preprocessor that takes Ada
sources with directives and produces Ada sources wouldn't cut it
because one would have to write the input files manually. The only
sensible input is the Objective-C specification files.

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

No, because you must export callbacks from Ada so the Objective-C
libraries can call them using dynamic typing and reflection. But Ada
does not have dynamic typing or reflection. That's the problem.

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

That's the job of the generator.

> 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

But that is also true of the GNUstep libraries. They call them
"frameworks" and there are several of them.

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

I know. Packaging nicely for your target platforms is important.

--
Ludovic Brenta.