Parrot-0.0.1

[Phil Hunt]

In article <MPG.1233dfb6145766d998968c at news.mop.no>
           earlybird at mop.no "Alexander Staubo" writes:
> 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?

No.

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

This is a good point.

One of my main motivations for wreiting Parrot is a dissatisfaction for
existing GUI building tools (at least the ones I've used).

This problem occurs with lots of GUI builders. One solution is to
put comments in the output of the GUI tool like this:

   //***** user code starts here
   //***** user code ends here

And then the GUI builder can read in the code the user has written.
I don't like this solution, IMO it looks ugly, and Parrot will use
a different solution: source code output by Parrot will go in a 
different file to source code written by the programmer. This is 
similar to tools like yacc -- the programmer doesn't directly alter the
file produced by this utility.

In Parrot, this will work by subclassing. Consider this except form
a .par file:


window @MyWindow {
   ...lots of other stuff here...
   button @start "Start"
   button @stop "Stop"
}


A Parrot backend will typically produce source code defining a class
MyWindow, in a particular programming language and GUI API, so a 
Python/Tkinter backend might produce something like this:


class MyWindow(DefaultWindow):
   ...lots of other code here...
   def start_pressed(self):
      # [Start] button pressed; this should be overridden 
      pass
   def stop_pressed(self):
      # [Stop] button pressed; this should be overridden 
      pass


Then the programmer writes their own file, which contains a subclass
of MyWindow, which contains method implementationd for start_pressed()
and stop_pressed().


> 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,

Yes. But the programmer shouldn't directly be altering Parrot's
output script anyway.

> A more interesting approach would be to create a Python framework that 
> loaded such Parrot scripts and instantiated necessary objects at 
> runtime.

I intend to write a Parrot backend that outputs a file in Glade XML
format. I believe there already exist libraries that will do what
you suggest with Glade XML, so Parrot will be able to do it this
way. Parrot is intended to have multiple backends, so both approaches
can be used.

I am also intending to write a Glade XML frontend for Parrot, so
for example, one could use Glade to build the GUI, import the
Glade file into Parrot, and create Python/Tkinter code from this.

> 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.)

Glade XML format is similar (but is XML obviously); I will be looking 
into its suitability as a universal backend format for Parrot.
 
> 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.

Parrot will have thre same property. In Parrot .par format, ``@'' 
does this:

   button @myButton "Some Text"

means that the button will be known internally to the code as 
``myButton''; this is irrespective of where it appears on the 
screen.
 
> Please don't construe my comments as being anything but constructive 
> criticism. 

Youtr comments are welcome.

> I want great GUI tools for Python, too.

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