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,c32fe290813aec20 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: New Ada portable GUI Library? 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: <6d63c543-0a35-4c39-a330-98c63a24f64d@i3g2000hsf.googlegroups.com> <1365533.nRhg4MZKNK@linux1.krischik.com> <4e5ffa74-e1d6-4e80-9dd9-824df475a60c@e10g2000prf.googlegroups.com> <970df333-8c12-4f5d-b32b-ded6a84a0195@v4g2000hsf.googlegroups.com> <187iruircnfuu$.oc2g47zys18k.dlg@40tude.net> <29b4fb7f-afb5-4428-9a73-2bac655b3a27@k39g2000hsf.googlegroups.com> Date: Sun, 13 Jan 2008 11:06:33 +0100 Message-ID: <14ilupzt2jywp$.up5hy9th8dnt$.dlg@40tude.net> NNTP-Posting-Date: 13 Jan 2008 11:06:35 CET NNTP-Posting-Host: 14e7a025.newsspool2.arcor-online.net X-Trace: DXC=Q\MiFn=JGdlm7>ihJR;B_cA9EHlD;3Ycb4Fo<]lROoRankgeX?EC@@`^3M?=]jG`Ma[6LHn;2LCVn[ On Sun, 13 Jan 2008 01:11:04 -0800 (PST), Lucretia wrote: > On Jan 13, 8:13 am, "Dmitry A. Kazakov" > 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