Python GUI

[Phil Hunt]

In article <37B0E67D.27F8D2ED at prescod.net>
           paul at prescod.net "Paul Prescod" writes:
> Phil Hunt wrote:
> > In article <37B02965.B1FE0E8D at prescod.net>
> >            paul at prescod.net "Paul Prescod" writes:
> > > Have you looked into XUL,
> > 
> > Glade is a GUI application that allows you to build a window visually.
> 
> Okay, but I saw a reference somewhere to Glade having a declarative file
> format that could be converted into code to build the GUI. I was mostly
> talking about the declarative file format.

I think I will have to have a look at Glade. My understanding is that 
it uses its declarative file format to save/load UI definitions that
people are working on.

If Parrot could read/write Glade's format, that would be good, as
then people could write a UI in Glade and export it to any
backend that Parrot supports.

> > My system (provisional name: ``Parrot'') is a command-line application
> > that takes an ascii file as input, and outputs a file containing source
> > code in your favourite language, to build the GUI.
> 
> Glade does that too, as long as your "favorite language" is C. :)
> 
> I don't understand why you would take a code generation approach,
> though. My professional opinion is that code generation is yucky. :) It
> takes no more effort to write a "Parrot reader" for each language --
> especially if Parrot uses the language's built-in XML support (oops.
> scratch that). Seriously though, XML aside, why bother with code
> generation when you can just do everything dynamically? Read the parrot
> file and make the objects on the screen. The performance shouldn't be
> much different and the extra dynamicity will make your life easier and
> make the tool cooler to use. "I'll just generate a modified parrot file
> and reload."

That is a persuasive argument. One counterargument would be that 
any application that uses that approach would need a built-in
XML parser and Parrot run-time library, thus creating code bloat;
however, Parrot is explicitly intended to support multiple back-ends,
so there is no reason it couldn't support both approaches.

What I am hoping is that once I have written a few back ends
(Python/tkinter, and HTML will probably be the first, and the back
end API is somewhat stable, I will be able to interest other people
in contributing backends. The ultimate aim is a universal front end:
you learn it once, and you can then easily write GUI apps for
any programming language and toolkit. And if Parrot can read/write
files from Glade, or other graphical gUI builders, it will be the
best of all worlds.

> > >  * it can be trivially parsed with existing code written in several
> > > languages
> > 
> > True; I don't think a parser for Python will be too difficult to
> > write: my provisional spec only has 12 productions.
> 
> These specs always start out small. :)

Yep, fraid so :-)
 
> > True, but writing classes implementing recursive tree-structures
> > is almost trivial in Python. (One reason I like it).
> 
> Wait until you get to the TCL version!

I had a look at Tcl; I think I will pass on that one (and the Perl 
one) :-).

> > I will stick with my current format; but adding a feature to
> > import/export to XML shouldn't be too difficult -- then I'd have
> > the best of both worlds.
> 
> True enough. I think history shows that one syntax or another always
> ends up dominating, though. Lisp had two syntaxes once...

-- 
Phil Hunt....philh at vision25.demon.co.uk