up with PyGUI!

[Carlos Ribeiro]

On Fri, 24 Sep 2004 10:17:06 -0400, Ed Leafe <ed at leafe.com> wrote:
> On Sep 24, 2004, at 10:01 AM, Carlos Ribeiro wrote:
> > [...my sample...]
> > class MainFrame(FrameDescription):
> >
> >     class b1(ButtonDescription):
> >       size = (40, 40)
> >       text = "b1"
>
> [...your question...]
>         How is this more powerful/flexible/robust than something like:
> 
> class MainForm(dabo.ui.dForm):
>         def __init__(self, parent=None):
>                 self.addObject(ButtonDescription, "b1")
>                 self.b1.Size = (40,40)
>                 self.b1.Caption = "b1"

Ok. I'll try to answer your questions, but first some background is
needed to focus the discussion.

We can broadly define three ways to implement GUI description: (a)
Imperative, (b) Data-driven and (c) Declarative. Dabo uses a
imperative approach (as do wxPython and almost all other GUI packages
for Python). Some packages are available which take a description of
the UI and build it, using XML or some other intermediary data
representation. Glade (for GTk) works this way. I'm using a
declarative approach -- using Python native class declarations to
build the UI definition.

Why do it this way? First of all, it's an *experiment*. It's something
I'm doing because I feel that it has potential to be better than other
approaches. It's also based on my experience with other tools. Delphi
forms are stored in a intermediate format that is read by the
application; it's really data driven, but the language "reads" for the
programmer as a declarative language. It's much more readable than,
for example, a XML file or a Python dict storing the UI definition. I
also remember the old days of dBase 2 and FoxPro (for DOS), where it
was easy to build data entry screens with just a few lines of
declarations embedded in the same program, with no need to create
separate data files, etc.

What I'm trying to do is to bridge the last gap here: having a
readable declaration of the interface, written in pure Python code, in
such a way as to allow the programmer to work with a single language
all the time. As I said, there's nothing wrong with other approaches,
but I *think* that my approach will show its value once we start to
use it for day-to-day coding. I may be wrong, but why can't we try it?

DESIGN GOALS

The system is being designed for readability and flexibility. It's not
being designed to be powerful, in the sense of fine control over the
UI, but to be as simple to use as possible, and both things (power vs.
simplicity) are at odds sometimes. I'm yet to see how big a compromise
must be made.

The first part is the metacontainer engine. It's a metaclass that
handles creation of nested classes in such way as to preserve some
information that is lost when Python parses the code; namely, the
ordering of the declarations. It also converts nested classes into
instances, which is needed for later use.

This engine is totally independent of its use. You can use the engine
anytime a declarative language is useful: form design, reports,
database declarations, etc.. (In fact, the design was inspired by Ian
Bicking's sqlobject way to declare object entities; I just wanted a
way to generalize it for other stuff).

Over this engine (that is already working and is nicely encapsulated),
I'm building a generic Form class. I could be doing the same for
databases, or for reports. Everything will share the same engine and
the same way to write declarations. What will change is the base
classes used for this purpose, and the way the resulting class
definition will be used.

The class description works together with a renderer object. They
collaborate to convert the declaration of the UI into a real
representation -- for example, a wxFrame filled with all controls
needed. It's probably slower than executing code written by hand. But
it's easier to write, because the engine can handle a lot of the stuff
that has to be done manually by the programmer.

This approach is not being design for speed, but nothing prevents it
from being fast. A good part of the "black magic" is done by the
metaclass when the class declaration is first read, parsed and
byte-compiele by Python. The result of the rendering can also be
cached for later use, so it's not really needed to render it everytime
it's needed.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com