Re: Development process in the Ada community

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204150628.548b23e8@posting.google.com...
>
> Since that's essentially what Gtk is, what precisely would be the
> advantage of doing it ourselves rather than leveraging off of the Gtk
> work like the GtkAda folk have done?
>
I wouldn't be opposed to declaring GtkAda the annointed answer - with some
eye toward extending its capabilities to be more useful while remaining
portable. What are the odds we'd get the vendors to agree that this was The
Moving Forward Plan?

I think I had something else in mind - GtkAda does store the description of
a GUI in XML, but ultimately it generates code that is compiled/linked for a
given platform. What if there was an engine that interpreted an XML
description of a GUI and you blipped XML text back and forth between the
engine and the Ada program by some convention? Interpreting the XML at
runtime has a lot of advantages and if the connection between the engine and
your Ada program was over TCP/IP, your apps automatically work over the net.

Its not as if you can't do this now by rolling-your-own & working with some
existing things, but why couldn't there be a "conventional answer"?

Something akin to this might make a better answer for a number of reasons.
One of which is that an XML based solution would reduce to a relatively
simple interface for the program that would mean a vendor could be
"compliant" with it without having to do a lot of work. The other is that on
the engine side of it, vendors can distinguish themselves with entirely
different looks-and-feels if this seems desirable. In a sense, it would let
the Ada developer develop as if there were a standard GUI, without actually
needing there to *be* one.

IIRC, Mozilla or someone out there was working on a "standard" XML markup
for GUI descriptions. (Maybe someone can post a link? I seem to have lost
track of it) Starting from here and defining a communication mechanism and a
DOM and you're just about there. Then all you have is the hard part of
generating the XML GUI engine that isn't a gross resource hog. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com