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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!feeder2.cambriumusenet.nl!feed.tweaknews.nl!83.128.0.11.MISMATCH!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!xindi.nntp.kabelfoon.nl!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: ANN: Ada industrial control widget library v1.0 released Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: Date: Wed, 16 Feb 2011 14:57:44 +0100 Message-ID: NNTP-Posting-Date: 16 Feb 2011 14:57:44 CET NNTP-Posting-Host: bf5f8196.newsspool2.arcor-online.net X-Trace: DXC=<4KeJ[Djjf8LNKYb?b>076A9EHlD;3Yc24Fo<]lROoR18kF7enW;^6ZC`4\`mfM[68DC3Ga[Mo11eNM7 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:17299 Date: 2011-02-16T14:57:44+01:00 List-Id: 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