ANN: Ada industrial control widget library v1.0 released

ANN: Ada industrial control widget library v1.0 released

[Dmitry A. Kazakov]

The library is intended for designing high-quality industrial control
widgets for Ada applications.

The widgets are composed of transparent layers drawn by cairo. The widgets
are fully scalable graphics. Time controlled refresh policy is supported
for real-time and heavy-duty applications. The library supports caching
graphical operations and stream I/O for serialization and deserialization.
Ready-to-use gauge and meter widgets provided as samples as well as an
editor widget for WYSIWYG design of complex dashboards. The software is
based on GtkAda and cairoada, Ada bindings to GTK+ and cairo. 

   http://www.dmitry-kazakov.de/ada/aicwl.htm

Comments and suggestions are welcome.

P.S. Thanks to Damien Carbonne for making cairoada binding available.

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

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

[Yannick Duchêne (Hibou57)]

Le Sat, 12 Feb 2011 15:22:12 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>
>    http://www.dmitry-kazakov.de/ada/aicwl.htm
>
> Comments and suggestions are welcome.

In "2.6.4. Text transformation", an image reference is broken.

Seems this could be useful for sound-processing applications too, not just  
industrial.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

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

[Dmitry A. Kazakov]

On Mon, 14 Feb 2011 16:34:43 +0100, Yannick Duch�ne (Hibou57) wrote:

> In "2.6.4. Text transformation", an image reference is broken.

Thanks, I have uploaded the missing image.

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

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

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:

> The library is intended for designing high-quality industrial control
> widgets for Ada applications.
> (...)
> 
>    http://www.dmitry-kazakov.de/ada/aicwl.htm
> 
> Comments and suggestions are welcome.
> 
> P.S. Thanks to Damien Carbonne for making cairoada binding available.

Thanks, looks like a great piece of work, and I always envy your 
documentation webpages. Are they automatically generated from source?

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

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

[Dmitry A. Kazakov]

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

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.

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

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

[Alex R. Mosteo]

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.

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

[Dmitry A. Kazakov]

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

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

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:

> On Wed, 16 Feb 2011 11:45:13 +0100, Alex R. Mosteo wrote:
> 
>> (snip)
> 
> 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.)

Thanks, this is the kind of stuff that goes over my head, and where I can 
really use other's knowledge. Instructive, even if it the subject is purely 
hypothetical at this time.

Alex.

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

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

[Pascal Obry]

Le 12/02/2011 15:22, Dmitry A. Kazakov a �crit :
>     http://www.dmitry-kazakov.de/ada/aicwl.htm

Looks really nice, great work!

Thanks for sharing.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

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

[Rick]

Thanks Dmitry
This package is a wonderful contribution and a great help to people
who, like me, don't have the command of the language to create such
things for themselves.  For example, I would never have thought of
doing this in layers.

The question now is about controls.  Is there a package which gives us
mouse-useable graphics of rheostats, slider controls etc.?  That's the
other side of a control panel.

Thanks again

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

[Dmitry A. Kazakov]

On Thu, 17 Feb 2011 15:42:05 -0800 (PST), Rick wrote:

> The question now is about controls.  Is there a package which gives us
> mouse-useable graphics of rheostats, slider controls etc.?  That's the
> other side of a control panel.

The GTK/GtkAda. Here are screenshots of some standard GTK widgets:

http://www.adacore.com/wp-content/files/auto_update/gtkada-docs/gtkada_rm/gtkada_rm/screenshots.html

My library sits on top of GTK.

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