Parrot-0.0.1

[Alexander Staubo]

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 
be intermingled.

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 
language:

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
  end
  object MyEdit: TEdit
    Left = 32
    Top = 16
    Width = 209
    Height = 21
    TabOrder = 1
    Text = 'This is an edit field.'
  end
end

(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_