workaround for generating gui tools

[Bengt Richter]

On Sat, 9 Apr 2005 19:22:16 +0200, "Fredrik Lundh" <fredrik at pythonware.com> wrote:

>Reinhold Birkenfeld wrote:
>
>> It's evil anyway (for more complex applications) to put GUI construction
>> in your code. GUI should be described appropriately in data files.
>
>why use data files when you have an extremely powerful programming
>language in your toolbox?  the advantage of building UI's in Python is
>that you can quickly create "domain specific UI languages", and use them
>to generate the interfaces for you.  UI editors may be useful for trivial
>applications, but if you're doing complex stuff, you sure want domain-
>specific abstractions.  Python gives you that, XML files don't.
>
Suppose tkinter elements all had a standard python property called, say, textview,
and for any given element in a GUI hierarchy, you could get and set and delete
this textview property, with suitable side effects. If you wrote python like
    print mywidget.textview
You might see something like Delphi's representation of a nested "panel" widget
with a label, text entry slot, and button (excerpted from a full form representation):

"""
  object Panel1: TPanel
    Left = 400
    Top = 160
    Width = 185
    Height = 113
    TabOrder = 0
    object Label2: TLabel
      Left = 24
      Top = 16
      Width = 65
      Height = 13
      Caption = 'Example label'
    end
    object Edit1: TEdit
      Left = 24
      Top = 32
      Width = 121
      Height = 21
      TabOrder = 0
      Text = ' (example text entry)'
    end
    object Button1: TButton
      Left = 24
      Top = 64
      Width = 121
      Height = 25
      Caption = 'Example Submit'
      TabOrder = 1
    end
  end
"""

(The parent form or GUI element specifies other things that are inherited (e.g. fonts etc),
so those aren't part of the widget representation unless you have locally
edited those attributes one way or another, in which case they would show up)

(I might add a standard TEXTVIEW_VERSION = ... line as the first line of output
in case you wanted to save a design for later (perhaps much later) but Delphi
doesn't seem to).

Anyway, with a textview property you could write

    open('mywidget_v2.txt','w').write(repr(mywidget.textview)

and if the textview property round-tripped, you could edit mywidget_v2.txt
with emacs or vim or a program, and then (just as an example) write

    mywidget.textview = open('mywidget_v2.txt').read()

and see the changes. Creating or deleting mywidget would be modifying the textview
of the parent, if you were doing it via textview, except that del mywidget.textview
might effectively delete mywidget from the parent. Not sure what would be most useful.

The textview is an alternate and fairly programming-language-agnostic representation
of a GUI design element. Obviously it would not be much of a transformation to convert
to nested python dict representation for the above (and for a python interface to tkinter
that might be better than text). It would not surprise me to find that someone has
done a tkinter walker (maybe it's built into tkinter, I haven't dug) that does something
like this for the read view, but I wonder about the round trip replacement write.

Anyway, I think this kind of programming-language-agnostic representation may be what
Reinhold is getting at, and the "evil" being non-programming-language-agnosticism
in GUI design representation (though textview representation syntax would be a language syntax too ;-)

Using Delphi's conventions might permit interesting interchange with the Delphi world, and I know
there is some Delphi/Python synergy being pursued, though I haven't looked into it, so I'd bet
there is python code somewhere translating between Delphi and tkinter. I just thought of this
textview property to help make my take on Reinhold's post clear, but I could see it making
GUI design interchange in general easier to have a standard representation for that purpose.

XML is too crufty for my taste, but the idea of a very broadly applicable definition of
useful pure abstractions with standard concrete representations appeals to me (I know of ASN ;-)
IMO XML has gotten a place in the world because it works well enough that people
who want to get other work done can't wait for it to be replaced with something better,
not because it's the best thing. Sort of like how MSDOS got its place in the world.

Alternatively, GUI elements could have registrable encode/decode methods with
some kind of UniGUIcode abstract core ;-) I kind of like that, off hand...

Regards,
Bengt Richter