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,b6df8f8501cf7275 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.74.74 with SMTP id r10mr9338238wiv.3.1356742119506; Fri, 28 Dec 2012 16:48:39 -0800 (PST) MIME-Version: 1.0 X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 78.192.65.63 Path: l12ni258773wiv.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!nntpfeed.proxad.net!news.muarf.org!news.ecp.fr!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Easiest way to build Qt/Gtk interfaces for Ada programs Date: Fri, 28 Dec 2012 18:48:37 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87072854-0f81-41fd-8cb0-ede78fccf6e7@googlegroups.com> <52aed30c-1fd3-407e-be52-2c366b9002d6@googlegroups.com> <49ad97eb-fac1-49f0-a4ea-2dd79fa803d0@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1356742119 12326 69.95.181.76 (29 Dec 2012 00:48:39 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 29 Dec 2012 00:48:39 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-12-28T18:48:37-06:00 List-Id: wrote in message news:49ad97eb-fac1-49f0-a4ea-2dd79fa803d0@googlegroups.com... ... > Thanks. That is what I was looking for!! So, the workflow seems to be: > creating the widjets with Glade, then using Gate3 to generate Ada code, > then using the generated code in Ada programs. I suspect that this workflow is the problem that Dmitry is referring to. It doesn't mesh well with incremental, agile development, where you are constantly tweaking both the GUI and the code that supports it. I realize that this makes it possible for one "front-end" to support many different code generation schemes (and that code generation is the "easy" part of a GUI builder), but it is just too far from the sort of control needed to make real, living applications. The Claw Builder (for instance), supports specifying how the package specification corresponding to a dialog box will look, whether it is just a single subprogram call (for a dialog that does all of its work in call-backs), a subprogram call that returns a visible record (of the data specified by the box), or whether the dialog type is also visible (so that multiple instances can be created). These sorts of decisions can't be productively made by the software alone, and only generating a single template is never going to have the flexibility needed for these things. Of course, the other approach is a heck of a lot of work, one reason why the Claw Builder's development has stalled... Randy.