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

["Alex R. Mosteo" <alejandro@mosteo.invalid>]

Dmitry A. Kazakov wrote:

> On Tue, 15 Feb 2011 11:02:33 +0100, Alex R. Mosteo wrote:
> 
>> ... and I always envy your
>> documentation webpages. Are they automatically generated from source?
> 
> No, manually. When I write documentation I always find lots of errors and
> inconsistencies in the design and interfaces. So I consider hand-written
> documentation important, at least to me.

I was wondering about management of consistency when you release upgrades, 
mostly... Doesn't it become a pain sometimes? Especially because your docs 
are so exhaustive.

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

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.

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.

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. And interaction, and 
multithreading...

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. 
And I wonder how/if many access types would be needed.

> BTW, this is one of the reasons I always wanted we had a purely Ada
> low/middle level graphic library, rather than GTK or Qt.