Re: ANN: Ada industrial control widget library v1.0 released

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

On Wed, 16 Feb 2011 11:45:13 +0100, Alex R. Mosteo wrote:

> I was wondering about management of consistency when you release upgrades, 
> mostly... Doesn't it become a pain sometimes?

Not really, because I always change both the interfaces and the
documentation almost the same day.

Most problems are related to the GPS's refactoring tool. It is too
convenient! (:-))

>>> I wonder how much overhead (in terms of noticeable CPU use or user
>>> perceived lag) would an abstract Ada intermediate layer would add to this
>>> kind of library, in order to make the backend switchable. I have done so
>>> for my (very limited) presentation needs, so in my case it is not an
>>> issue, but when I see such a nice widget library I wonder if it could be
>>> made usable not only with GTK (even if with some sacrifices).
>> 
>> What backend do you have in mind? And, more importantly, what kind of
>> design "of switching." I.e. is it basically porting GTK/GDK/Cairo to some
>> low-level graphical/OS framework like Windows or X11. Or is it porting the
>> application level library from GTK to something else (e.g. Qt). The former
>> is quite doable, but remains GTK. The latter is very difficult to
>> estimate, but I guess as very difficult. Each move up away from raw
>> rendering towards the application layer makes things more and more
>> complicated.
> 
> If I understand correctly, is more about the latter. Since I'm not sure I 
> used the term 'backend' properly, I will briefly describe what I have. It 
> mostly build on two interfaces:
> 
> type Drawer is limited interface; 
> --  This is the 'output' device
> 
> procedure Draw_Line (Into : in out Drawer; X1, Y1, X2, Y2 : ..) is abstract;
> --  There are others for changing color, filling a rectangle and simple text
> 
> type Drawable is limited interface;
> --  Something that I need to draw
> 
> procedure Draw (This : Drawable; Into : in out Drawer'Class) is abstract;
> --  Here I do all the drawing in an 'isolated' way.

(BTW, Draw must be doubly-dispatching on the shape and the drawing context,
but we cannot do this in Ada.)

> Then, I have Drawers for Gtk (over a Gtk_Drawing_Area) and the Stage robotic 
> simulator (using the Graphics2D interface). For me this is quite handy 
> because I can overlay my figures on the simulator, but also can seamlessly 
> get a Gtk display for real experiments without the sim. And I guess I could 
> do a e.g. Qt implementation with relative simplicity.

Here you just have outlined a possible design of an Ada graphic library. It
would be very nice if Ada included something like this. The case before my
eyes is C#. It is adopted mostly because there are lots of graphic
libraries ready-to-use.

> I have also some extra classes for buffering of drawing actions and mixing 
> of Drawables into a same Drawer, automatic scaling and so on, but nothing 
> really extra-fancy or complicated that the overhead becomes an issue.

So long you are staying within pure drawing. But in order to create a
drawing context you will need to maintain devices (e.g. for PDF rendering),
widgets (e.g. for screen rendering) etc.

> And this is basically what I meant. Since I do not need that much, for me 
> it's enough. I can see how supporting features that can be or not available 
> on the final device can complicate things.

For example GDK has drawing primitives of its own. But they are
insufficient for meaningful vector graphics. So GTK is using Cairo on top
of GDK. Now if Ada would switch from Cairo to something like GDK, you would
need to implement 90% of Cairo in the "bindings." Why then not to rewrite
Cairo from scratch?

> And interaction, and multithreading...

Yep, signals and handlers mapped onto a static mesh of types with signal
parameters typed and statically checked. Signal emission as an entry point
call etc. This is a huge problem. I don't even know how to approach it,
given that ARG would commit itself to change the language appropriately.
(But they surely won't!)

> And that's why I asked on your opinion about the difficulty of designing 
> something like this properly from the start to have an abstract Ada layer.

I tried a bit by defining interfaces of drawable layers. I intentionally
didn't make layer a GObject for this reason. But that was the easy part.

> And I wonder how/if many access types would be needed.

Lots, because GUI objects involved do not have their life times bound to a
static scope. Objects are created and put into some container (e.g. widget)
of class-wide instances. Ada cannot this without access types for many
reasons. Similarly when an object is referenced, you need to be able to
return it by-reference from a getter/setter function. By-reference result
was ditched in Ada 2005 in favor of meaningless and useless limited-valued
functions. There are other issues too, like dispatching on bare tags
(generic dispatching constructor does not really work), immutable results
(that is when you reference a limited element of an immutable container,
the subtype of the result must be immutable. But when the container is
mutable, the result is mutable too. C++ solves it by overloading, but I
don't like that.)

I think it is possible to get rid of access types in GUI, if ARG considered
this as a goal and changed the language accordingly. Nowhere in GUI objects
are referenced without their containers and there is always a dedicate
owner of each object.

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