V - GUIDO !!! was Re: Pirate -> RAD

[Phil Hunt]

In article <37D2B4FD.9F6D9098 at megsinet.net>
           davidopp at megsinet.net "David Oppenheimer" writes:
> Dear Phil,
> 
> I don't know quite how such a program could utilize Parrot.
> I am not averse to
> making such a program as V - GUIDO compatible with the other major GUI tool
>  kits such
> as Tkinter and PyGtk except for the fact that this would involve a tremendous
>  amount
> of additional work for each GUI tool kit (Unless Parrot does some kind of
>  "magic" so
> that I wouldn't even have to concern myself with that). 

That's the whole point of Parrot: you give a GUI description to 
Parrot, and Parrot outputs code in whatever format you want (assuming
that a Parrot backend exists for that format).

For example, your GUI description file is called mygui.par

If you tell Parrot, at the command line:

   $ python parrot.py mygui.par Pytk

Then Parrot will attempt to process mygui.par with its Pytk backend
(which produces Python/Tkinter source code). Parrot will put
its output into "mygui.py".

Similarly:
   $ python parrot.py mygui.par Html

Tells Parrot to process "mygui.par" with its Html backend
(which incidently is stored in file HtmlBackend.py -- all backends
use this naming convention), creating the output file "mygui.html",
which is a web page laid out to look like the widgets you have 
defined.

> There are different looks
> and feels to all of the GUI tool kits out there.  How would Parrot
> account for these differences? 

There are two sorts of L&F differences between GUI toolsets: 
(1) they look slightly different. (2) they allow different widgets.

For (1), Parrot creates widgets for that widget set. Yes they look
a bit different, but so what? Qt buttons/checkboxes/menus look
different from the same widgets in Tk or Gtk, but they all work
pretty much the same.

For (2), Parrot will just have to ignore a particular widget if that
widget is not supported by the particular widget set that a backend
is writing to. But this mainly applies to exotic widgets, not
common-or-garden ones such as buttons, labels, checkboxes, etc.

Here is a short excerpt from a Parrot .par file:

colLayout {
   button @orderPizza fcol=red "Order Pizza"
   label fcol=green "Which toppings do you want:"
   checkbox @topping1 "mozzarella"
   checkbox @topping2 "pepperoni"
   checkbox @topping3 "bacon"
   checkbox @topping4 "anchovies"
}

If Parrot was using a backend that allowed foreground colours
to be changed on widgets, the button would have red text, and
the label would be in green. However, if the backend didsn't allow
this, those attributes would be ignored.

Note that Parrot will write to an error log when it is forced to
ignore an attribute or widget. (This hasn't been implemented yet).

> Would a user of V-GUIDO choose which kind of code
> they wanted the program to output,

Yes, as I envisage it.

> and then a Paxo file with an
> argument for that type of output be

Paxo files define a GUI layout. They don't say what Parrot backend
to use to process that layout.

> sent to Parrot and then Parrot would do this on its own?

Almost; the backend to use is defined on the Parrot command line,
so V-GUIDO could use the system() call to run Parrot. 

Alternately, since Parrot and V-GUIDO are (will be) both written
in Python, V-GUIDO could just call the relevant Parrot function.


> I don't know how much additional work would be involved to maintain
>  compatibility  as
> the tool kits themselves change.  It would help to understand
> exactly how Parrot works and how Paxo works.

See http://www.vision25.demon.co.uk/prog/parrot.html for details
(from which you can download the Parrot tarball; within the
tarball, the file guicomp.txt is my original spec, and defines
most of the ideas that will go into Parrot).

> I am not averse to
> incorporating useful existing code into
> this program just as long as it makes things easier not just
> more complicated.

This is a good point.

For you to use Paxo (and the related Paxi format, which currently
exists only in my head :-)), I would have to document them more 
thoroughly.

I am happy to do that, and collaborate with you on designing the
details of these formats, if that is what you want.
 
> The advent of a WYSIWYG GUI tool such as V - GUIDO will be a
> great advance and may
> help to give Python a bigger following.  The trick will be to
> make it easy enough for
> a beginner to use and at the same time powerful enough for an
> advanced programmer to
> want to use it too.   I have been looking at several GUI makers
> out there to figure
> out which features would be good to include.

I think it is important to have a good idea as to what features do 
and do not work in visual GUI builders, so you can pick out the
best, and avoid repeating others' mistakes.

Have you ever used IBM Visual Age for Java? Please don't make the 
GUI layout anything like that :-)

> Would it be appropriate to bring the the GUI SIG back from the dead and make
>  this a
> formal ongoing project?

Possibly. (I never knew there was a GUI SIG).

> Instead of arguing about which GUI tool kit is better,
>  we
> could focus our energies on creating V - GUIDO and making it
> compatible with all of the major GUI tool kits.
> 
> Sincerely,
> 
> David Oppenheimer
> 
> "Any Sufficiently Advanced Technology Is Indistinguishable From Magic."
> - Arthur C. Clarke

"Any sufficiently advanced operating system is indistinguishable 
from Linux" -- Jim Dennis


-- 
Phil Hunt - - - - - - - - -  philh at vision25.demon.co.uk
 - Linux will be 8 years old on 17th September! See: -
http://www.vision25.demon.co.uk/prog/linuxbirthday.html