Re: New Ada portable GUI Library?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 13 Jan 2008 01:11:04 -0800 (PST), Lucretia wrote:

> On Jan 13, 8:13 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Gtk and Qt are themselves thick bindings. It makes no sense to use them as
>> a low-level rendering platform. An all-Ada GUI design should IMO look like:
> 
> Yes, actually it does. Look at wxWidgets, they use Gtk as a base for
> Linux apps to provide a native look and feel. Not many people use
> direct X11 libraries for their DE.

Gtk is slow. And after all, there is GtkAda here. If you are prepared to
buy poor performance of Gtk and its alien to Ada design concept, then you
can branch from GtkAda 2.8 which was GMGPL, or maybe 2.4, I don't remember.
(In case you will go this path let me know. I am interested in such efforts
because I maintain the GtkAda contributions project.)

The only goal of a *true* Ada GUI library, IMO, could be a library which
would have a chance to become a part of the Ada Standard Library. So Gtk is
just non-starter here. We cannot depend on third-party libraries.

>> Ada GUI library
>> ----------------------------------------
>> Ada rendering platform abstraction layer
>>            |
>>    Ada   | Ada native bindings, engine-specific
>> -------- | -----------------------------
>>    X11   | Win32 GUI API
>>
>> The major problem is a good abstraction layer with a working concept of
>> inter-tasking signal handler composition. This is a weakness of most known
>> Ada GUI libraries.
> 
> No! At this level you don't need (or want) to implement tasking.
> That's the whole point of using a tiny C veneer as an abstraction for
> the stuff you might not be able to do with Ada easily (I'm talking
> about managing the C preprocessed code here). You implement the
> tasking at the higher Ada layer.

That will be too late to do with signals, and with the opposite direction
too, I mean imperative rendering commands. There is also the issue of
sharing OS rendering resources. All these things don't compose at the
tasking level. Your thin layer should have granularity of pair ms per any
primitive (with cloning non-sharable resources). Otherwise things will
block. Already rendering based on OS libraries does not satisfy this
condition. As for signal handling there is no chance to do it at all. This
implies that tasking must be present already at the bottom level of the
bindings. Otherwise, you will need to move signals to the upper levels, but
that is impossible because signals are already a part of the OS layer like
in X11 and Win32. And what would remain, SetPixel? In short, the OS layer
isn't thin enough.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de