On Sat, 9 Apr 2005 19:22:16 +0200, "Fredrik Lundh" <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
