New Ada portable GUI Library?
in [ADA]
|
Prev: Problem with saving file from GPS on Vista
Next: (slightly OT) Open Source licences? (was: Re: New Ada portable GUI Library?)
From: Phaedrus on 15 Jan 2008 20:47 I appreciate the ideals, but... Do you own a Swiss Army knife? Especially the big one. Does everything, even has a pen built in. Lots and lots of tools, but it isn't actually a very good tool. It's heavy, and it's a terrible knife. By trying to hit so many targets it's achieved a sort of cult status, but I wouldn't want to have to use it for anything other than emergencies. Sounds to me like you're trying to hit a similar target, and I suspect you'll have the same kind of results. If it's simple enough for newbies it'll be much too limited for the pro's, and anything that the pro's would appreciate would be over the head of the newbies. Remember, even having too many packages or too many functions/procedures/types in a spec can be enough to turn the young-un's away. A tool should be simple and coherent in design, easily described and intuitive to the user. That's why I suggested targeting something like the turtle graphics of GUI, with two words you've got a clear understanding of it. Oh, and it doesn't hurt if it's appealing to the masses, too! (Wouldn't it be great if people thought of Ada as the EASY, PAINLESS way to develop apps?) Brian "Randy Brukardt" <randy(a)rrsoftware.com> wrote in message news:fmjlg7$n36$1(a)jacob-sparre.dk... > "Phaedrus" <phaedrusalt(a)hotmail.com> wrote in message > news:13oqje6labldu58(a)corp.supernews.com... >> And you'll get better gas mileage, and your laundry will be 40% whiter, > your >> breath will be minty-fresh, and your naughty bits will be both naughtier > and >> bittier... > > Yes, that what we want (well, except for making ones naughty bits > itty-bitty > ;-). > >> It's a simple, portable GUI that will allow newbies to get consistent, > pleasant, >> portable results, and help professional, seasoned developers to get > consistent, >> pleasant, portable results :) > > Indeed, that is what we were trying to accomplish with Claw (other than > portability to non-Windows systems). Which only goes to show while it is a > good goal, it isn't easy to accomplish. > > OTOH, it really should be the goal, even if it isn't going to get > accomplished. I can't imagine why anyone would want to make something that > will only work for newbies, or has unpleasant results by default, or > whatever. It's better to set the goals high, so that you at least have a > chance to get near them. > > Randy. > >
From: Brian May on 16 Jan 2008 02:54 >>>>> "Martin" == Martin Krischik <krischik(a)users.sourceforge.net> writes: Martin> There is just one problem here: Both Gtk+ and QT are OO libraries which Martin> are not all that compatible with the Ada's OO way of live and this in Martin> turn mean that layer (2) and (3) might not be as tiny as we hope for. I am curious - in what why are they not compatible? -- Brian May <bam(a)snoopy.apana.org.au>
From: tmoran on 16 Jan 2008 03:16 > GWindows is OK - but it is missing Unix support. But maybe WINE could > help here. IIRC from some years ago, someone used WINE with CLAW successfully.
From: Martin Krischik on 16 Jan 2008 03:28 Ludovic Brenta schrieb: > Martin Krischik wrote: >> Ludovic Brenta schrieb: >> >>> Martin Krischik wrote: >>>> Ludovic Brenta schrieb: >>>> >>>>> Martin Krischik wrote: >>>>>> I have another suggestion: A GUI Library based on OpenStep [1]. >>>>> [...] >>>>>> [1] http://en.wikipedia.org/wiki/OpenStep >>>>> Do you mean a reimplementation of the OpenStep specification in Ada, >>>>> or an Ada binding to GNUstep (http://www.gnustep.org) ? >>>> The later. AFAIK GNUStep uses only a small message based dynamically >>>> typed API with a plain C specification. Qt and Gtk+ use huge OO API's in >>>> C++ or some kind of strange OO-C. > I agree that a static mapping doesn't make sense; that's why I was > thinking about a binding generator. A preprocessor that takes Ada > sources with directives and produces Ada sources wouldn't cut it > because one would have to write the input files manually. The only > sensible input is the Objective-C specification files. I see what you mean - and probably we would need both. I might aim high but I believe full integration should be the aim. And that means that class B written in Objective-Ada inherits from Class A written in Objective-C and Class C written in Objective-C++ inherits from Class B. Now I believe neither GtkAda nor QtAda currently offer that kind of support. >>> The stumbling blocks would be to implement Objective-C's reflection, >>> dynamic typing and garbage collection in Ada. In particular, >>> reflection and dynamic typing are alien to Ada's philosophy. >> You don't - you use the objc runtime which should provide all those via >> plain C functions. > No, because you must export callbacks from Ada so the Objective-C > libraries can call them using dynamic typing and reflection. But Ada > does not have dynamic typing or reflection. That's the problem. Neither had C or C++ - that is all done by the (now build in) preprocessor. >> But it will solve the biggest problem: the endless amount of methods. A >> GUI lib easily got 100 classes. Defining 100 classes is doable - but >> each class will have what about 20 methods. Yes 20 is realistic for GUI >> lib. That would be 2000 pragma imports - endless work. > > That's the job of the generator. Yes - which might use reflection to get the data needed. >>>>> would require both the Ada and Objective-C runtime libraries... >>>> Indeed - but that is not different from Gtk+ and Qt approach. And bare >>>> metal is only feasible for Windows but not for X11. >>> OK, Qt requires a C++ runtime like GNUstep requires an Objective-C >>> runtime. However, GTK+ only requires the C runtime >> That might have been the original idea, but soon they needed Glib2 - to >> make things easier. And then a few more: ATK, Cairo, Fontconfig, >> FreeType, Pango, Poppler, libPNG, libXML, libiconv, librsvg, pkg-config >> as of my last counting: >> >> http://gnuada.sourceforge.net/pmwiki.php/Main/PartnerProjects > > But that is also true of the GNUstep libraries. They call them > "frameworks" and there are several of them. Yep. I guess all of them, Gtk+, Qt, GNUstep and indeed Win32 are Runtimes of there own. Either we use one of those - or we create our very own all in Ada - which brings us very quickly to AdaOS ;-) . Martin -- mailto://krischik(a)users.sourceforge.net Ada programming at: http://ada.krischik.com
From: Dmitry A. Kazakov on 16 Jan 2008 03:47
On Wed, 16 Jan 2008 18:54:03 +1100, Brian May wrote: >>>>>> "Martin" == Martin Krischik <krischik(a)users.sourceforge.net> writes: > > Martin> There is just one problem here: Both Gtk+ and QT are OO libraries which > Martin> are not all that compatible with the Ada's OO way of live and this in > Martin> turn mean that layer (2) and (3) might not be as tiny as we hope for. > > I am curious - in what why are they not compatible? In Gtk+ there is a notion of class (of widgets for example). The class has properties and signals. An instance of that class inherits them from the class. So far so good. But this types system of Gtk+ is dynamic and weakly typed. (You can send any parameters you want) The incompatibility is firstly dynamic/weak Gtk+ with static/strong Ada and, secondly, it has an implementation of its own. Less important, but also incompatible: the messaging in Gtk+ is asynchronous in its interface while synchronous in implementation. (The worst possible combination, BTW) In Ada's OO messaging is all synchronous, concurrency is outside Ada's OO model. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |