From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c46082cf4d3df7b2 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!feeds.phibee-telecom.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: ANN: Ada industrial control widget library v1.0 released Followup-To: comp.lang.ada Date: Wed, 16 Feb 2011 11:45:13 +0100 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Injection-Date: Wed, 16 Feb 2011 10:45:55 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="w8g++bW4v3KH0+SqtoCNSw"; logging-data="16674"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19raDOULkhdhuGK8BhSWvm+" User-Agent: KNode/4.4.9 Cancel-Lock: sha1:JleN+R3gjlwZcXmU4/SWqb2lhGM= Xref: g2news1.google.com comp.lang.ada:17295 Date: 2011-02-16T11:45:13+01:00 List-Id: 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.