earlybird at mop.no
Mon Aug 30 01:25:01 CEST 1999
In article <935279776snz at vision25.demon.co.uk>,
philh at vision25.demon.co.uk says...
> It looks like version 0.0.1 of Parrot, my text-based GUI builder,
> will be ready within a day or so. It doesn't actually do anything
> useful yet; v0.0.1 is a technology demonstration version, which
> is intended to verify that the basic design is more-or-less
> sensible. Would anyone like to have a look at it, and possibly
> suggest some improvements? If so, tell me, and I'll put it on
> my website.
> Some information about Parrot follows:
[lots of stuff snipped]
I see no mention of two-way synchronization -- does this mean that once
you have written your Parrot script and edited the generated source,
your GUI is essentially locked?
The problem as I see it is that the descriptive language is not the
primary tool: once you've generated your GUI source code (eg., in
Python), you're separated from the original script. There's no way to
re-generate the GUI framework and preserving your logic -- because there
is no separation here between presentation and code. You assume they're
The issue is not just about good design, but also about practicalness:
If you run Parrot, its backend will (I conjecture) simply overwrite the
Python script, and your code will be lost. Unless each backend can
correctly discern what code is generated, and what is added by the user,
you'll have one hell of a time maintaining the source. Or perhaps you
expect people to run the Parrot generator only once.
A more interesting approach would be to create a Python framework that
loaded such Parrot scripts and instantiated necessary objects at
runtime. (This could equally well be done through a multiple backend
system, but once one has come this far, one might wonder whether a
"backend" system would be relevant anyway.)
For a good model on presentation/code separation, examine the Delphi VCL
framework. Your application is pure code; the rest is stored separately
in plaintext asset files, in a proprietary syntax not unlike your Parrot
object MyForm: TMyForm
Left = 191
Top = 103
Width = 333
Height = 131
Caption = 'Form1'
Color = clBtnFace
Font.Charset = DEFAULT_CHARSET
Font.Color = clWindowText
Font.Height = -11
Font.Name = 'MS Sans Serif'
Font.Style = 
OldCreateOrder = False
PixelsPerInch = 96
TextHeight = 13
object OkButton: TButton
Left = 32
Top = 48
Width = 75
Height = 23
Caption = 'OK'
TabOrder = 0
object MyEdit: TEdit
Left = 32
Top = 16
Width = 209
Height = 21
TabOrder = 1
Text = 'This is an edit field.'
(It's worth pointing out that, although you can edit these scripts, as a
rule you don't create these scripts yourself. They're generated by the
visual GUI builder. Most people don't even see these scripts.)
The Delphi IDE itself has a neat two-way synchronization mechanism that
allows you to edit the code and still remain 100% in sync with the GUI.
For example, let's say you bind some code -- an "OnClick" event handler
-- to a button. You can edit the button, move it around, or edit the
event handler's code, move _that_ around -- but the link between the
source code and the GUI description is never severed.
(The two-way engine actually uses its own parser. Because the language
-- ObjectPascal -- is sufficiently strict, it can transparent re-link
GUI-bound handlers by looking at their names and syntax. Contrast this
with other popular GUI builders such as Visual C++ and, afaik, Visual
Cafe, which use machine-readable comments to sync their source and GUI.
You can't really blame these shortcomings Java or C++ -- Delphi comes in
a nearly identical C++ version called C++Builder, which provides the
exact same two-way feature.)
Please don't construe my comments as being anything but constructive
criticism. I want great GUI tools for Python, too.
Alexander Staubo http://www.mop.no/~alex/
"`Ford, you're turning into a penguin. Stop it.'"
--Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
More information about the Python-list