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: Vadim Godunko on 13 Jan 2008 00:17 On 13 ÑÎ×, 02:01, Lucretia <lucret...(a)lycos.co.uk> wrote: > > Ada GUI Thick bindings > ------------------------ > Ada GUI Thin bindings > ------------------------ > C abstraction layer <- Can be provided via C or Ada depending on > lowest layer > ------------------------ > X11 | GtkAda | QT > Qt automatically limits you to GPL unless you have commercial Qt license, as well as GtkAda. Ada has bindings for both Gtk+ and Qt. Both bindings are large, complex and stable. Which advantages will have new GUI library?
From: Dmitry A. Kazakov on 13 Jan 2008 03:13 On Sat, 12 Jan 2008 15:01:43 -0800 (PST), Lucretia wrote: > Like I said, a thin C layer abstraction which is then imported into an > Ada library and turned into a proper Ada GUI with native controls, > this is the best way. For example: > > Ada GUI Thick bindings > ------------------------ > Ada GUI Thin bindings > ------------------------ > C abstraction layer <- Can be provided via C or Ada depending on > lowest layer > ------------------------ > X11 | GtkAda | QT > > I know three is an X11 binding to Ada but it is old and uses > preprocessing and if you want this library to be portable, you've no > hope where that's concerned. Hence the use of a set of C calls whether > these are written in C or Ada (with export(C, ...) pragmas). Gtk and Qt are themselves thick bindings. It makes no sense to use them as a low-level rendering platform. An all-Ada GUI design should IMO look like: Ada GUI library ---------------------------------------- Ada rendering platform abstraction layer | Ada | Ada native bindings, engine-specific -------- | ----------------------------- X11 | Win32 GUI API The major problem is a good abstraction layer with a working concept of inter-tasking signal handler composition. This is a weakness of most known Ada GUI libraries. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Lucretia on 13 Jan 2008 04:07 On Jan 13, 5:17 am, Vadim Godunko <vgodu...(a)gmail.com> wrote: > > ------------------------ > > X11 | GtkAda | QT > > Qt automatically limits you to GPL unless you have commercial Qt > license, as well as GtkAda. Yes, I know. I was just pointing out the way to do it. > Ada has bindings for both Gtk+ and Qt. Both bindings are large, > complex and stable. Which advantages will have new GUI library? 1) A nicer interface because both of these aren't pleasant. 2) A portable library, compile for many platforms - like wxWidgets. Luke.
From: Lucretia on 13 Jan 2008 04:11 On Jan 13, 8:13 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > Gtk and Qt are themselves thick bindings. It makes no sense to use them as > a low-level rendering platform. An all-Ada GUI design should IMO look like: Yes, actually it does. Look at wxWidgets, they use Gtk as a base for Linux apps to provide a native look and feel. Not many people use direct X11 libraries for their DE. > Ada GUI library > ---------------------------------------- > Ada rendering platform abstraction layer > | > Ada | Ada native bindings, engine-specific > -------- | ----------------------------- > X11 | Win32 GUI API > > The major problem is a good abstraction layer with a working concept of > inter-tasking signal handler composition. This is a weakness of most known > Ada GUI libraries. No! At this level you don't need (or want) to implement tasking. That's the whole point of using a tiny C veneer as an abstraction for the stuff you might not be able to do with Ada easily (I'm talking about managing the C preprocessed code here). You implement the tasking at the higher Ada layer. Luke.
From: Dmitry A. Kazakov on 13 Jan 2008 05:06
On Sun, 13 Jan 2008 01:11:04 -0800 (PST), Lucretia wrote: > On Jan 13, 8:13 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> Gtk and Qt are themselves thick bindings. It makes no sense to use them as >> a low-level rendering platform. An all-Ada GUI design should IMO look like: > > Yes, actually it does. Look at wxWidgets, they use Gtk as a base for > Linux apps to provide a native look and feel. Not many people use > direct X11 libraries for their DE. Gtk is slow. And after all, there is GtkAda here. If you are prepared to buy poor performance of Gtk and its alien to Ada design concept, then you can branch from GtkAda 2.8 which was GMGPL, or maybe 2.4, I don't remember. (In case you will go this path let me know. I am interested in such efforts because I maintain the GtkAda contributions project.) The only goal of a *true* Ada GUI library, IMO, could be a library which would have a chance to become a part of the Ada Standard Library. So Gtk is just non-starter here. We cannot depend on third-party libraries. >> Ada GUI library >> ---------------------------------------- >> Ada rendering platform abstraction layer >> | >> Ada | Ada native bindings, engine-specific >> -------- | ----------------------------- >> X11 | Win32 GUI API >> >> The major problem is a good abstraction layer with a working concept of >> inter-tasking signal handler composition. This is a weakness of most known >> Ada GUI libraries. > > No! At this level you don't need (or want) to implement tasking. > That's the whole point of using a tiny C veneer as an abstraction for > the stuff you might not be able to do with Ada easily (I'm talking > about managing the C preprocessed code here). You implement the > tasking at the higher Ada layer. That will be too late to do with signals, and with the opposite direction too, I mean imperative rendering commands. There is also the issue of sharing OS rendering resources. All these things don't compose at the tasking level. Your thin layer should have granularity of pair ms per any primitive (with cloning non-sharable resources). Otherwise things will block. Already rendering based on OS libraries does not satisfy this condition. As for signal handling there is no chance to do it at all. This implies that tasking must be present already at the bottom level of the bindings. Otherwise, you will need to move signals to the upper levels, but that is impossible because signals are already a part of the OS layer like in X11 and Win32. And what would remain, SetPixel? In short, the OS layer isn't thin enough. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |