Pythonic gui format?

[Patrik Blommaskog]

How about this:


def mogrify():
print "Mogrifying"

gui = window(title = "Hello World!") [
image(text = "nice pics here", pos = (5, 5), src = "img.png"),
text(opts = "italic") ["(some text here)"],
lst() [
"first element",
"second element"
],
button(action = mogrify, text = "Click Me!")
]


There may be some slight errors above, but the principle works for me.
The gui is described with valid Python code, and object order, types,
parameter checking etc works in the way you would expect in Python. If
you try not to think about how it abuses Pythons items, I find it quite
nifty.

I have a toy project where I build a gui like this, with two major
differences from your wishlist: (1) My code does not contain the actual
widget objects, but instead builds a tree that gets traversed to build
the gui objects. (2) The only parser I have right now builds html
documents with callback dispatching (using Turbogears). I envision
generation of gui code for locally executed GUI:s (e g wxPython) as
well. However, I see no immediate reason that you should not be able to
put the actual widget objects in the tree like illustrated above.

I did not in any way invent this method of description. If you are
interested, a more mature use can be found in Nevow
(http://divmod.org/trac/wiki/DivmodNevow) where they have a document
object model called Stan, using a similar method to generate xhtml
documents. I'd be happy to hear about other uses.

I'll leave it to others to have opinions about whether it is to be
considered pythonic.


- Patrik

 

[Atanas Banov]

ever considered doing the mapping this way?

window = [
["item", {'k1': 'v1', 'k2': 'v2'],
["otheritem", {'k1n': 'v1n', 'k2n': 'v2n'}]
]

it is as simple as it gets: for 1:1 mapping from XML, list of
Attributes becomes py List.
the list of Properties of an attribute becomes a py Dictionary

ps. you can do tuples instead of lists if immutable is ok.

 

[Christoph Zwerschke]

And finally, you could write your own ordered mapping type - but then
you loose the builtin syntax...

I still don't understand why so many objected there are no "use cases"
for ordered dicts when I tried to discuss these in a recent thread...
Actually I see them everywhere.

-- Christoph

 

[Bruno Desthuilliers]

Gregory Petrosyan a écrit :
(snip)

Your dicts example is nice, but this approach (and some others) lacks
one important feature: ordering of GUI elements. In XML, the order of
all elements is specified, and with dicts (or with very clean Georg's
model) it is not. (BTW remember topics about ordered dicts...)

(rereading this thread...)

Err... Wait a minute. Are you actually *sure* that there's a problem
with ordering here ? I mean (please stop me if I missed the point): a
Window is an object, right ? It has attributes (which are named, and
definitively *not* ordered - remember, object attributes are actually
stored in a dict). Now *some* of these attributes may well be
collections of other objects (ie: widgets...). And these collections
*can* be ordered.

window = {
'__class__' : 'Window',
'id' : 'dummy',
'title' : 'My Dummy Window',
'w' : 640,
'h' : 480
'widgets': [
{'__class__' : 'Widget',
'id : 'dummy1',
'handlers' : {
'on_click' : # damn...,
},
},
{'__class__' : 'Widget',
'id : 'dummy2',
'handlers' : {
'on_clock' : # dring...,
},
},
],
}

Braindead Stupid Simple, Isn't it ? (DH was *somehow* right: this is not
JSON, but this is exactly what JSON is to javascript).

As you see, what needs to be ordered is ordered. Now what we'd need
would be a way to represent callback (handlers) functions. The simplest
would probably be to forbid anonymous functions for callbacks, so we
could just store the fully.qualified.name.to.callback as string...

My 2 cents

 

[DH]

And what about true vs True and false vs False ?-)

The syntax is the same, except for, as I said, JSON's multiline comments.
The semantics do differ, but that has nothing to do with the user's
question, about an alternative to XML for data representation. You
can use "true" or True or "null" or None or whatever semantic values
you want.

You can use the JSON library if you want. But there really is no
need in this case. Just import the file containing the dicts and lists.

No, Python's dicts and lists are not JSON.

Which are syntactically identical to JSON's.

> They are Python's dicts and
lists. JSON stands for JavaScript Object Notation, and AFAIK, Python and
javascript are two different languages

No shit.

 

[Gregory Petrosyan]

Bruno: in your original example, how can it be specified that image
should be placed before text? Of course, it *can* be done with one
extra level of wrapping of gui elements in list... did you mean that?

Patrik: thanks a lot!
Stan (the way it represents XML) is almost what I am looking for.

 

[Ivan Voras]

The reasons given in the blog were fairly precise. I think "only on
vague[...]" is misleading here. The idea of the article was to educate a
Java user how to change his or her frame of reference to better use Python.

The author was not being territorial as you are implying.

What triggered me is the presence of lots of absolute statements like
"XML is not the answer. It is not even the question.", "In Python, XML
is something you use for interoperability, not your core functionality,
because you simply don't need it for that." and similar. Though the
author says at the end "There are also other, very rare, architectural
reasons to need XML" he then proceeds to say "Trust me, they don't apply
to your app." instead of educating the reader what they are and make him
conclude that for himself. The article is actually quite good, but in
this particular section the author doesn't explain his advices well.
Personally, I the approach "X is good because of Y, except when Z and W,
when it's the other way around" better, since IRL it's always so.

Mentioning (again, not explaining!) LISP to state XML is laughable is
kind of lame, especially since the focus of the article are Python and Java.

Again, it's good, but I'd like more explanations and conditionals in
that paragraph

 

[Fuzzyman]

You are right of course. Those "examples" are really bad, and, most
of all, really un-pythonic.

Thanks for JSON. It's more clean&simple than XML, but my main idea is
to remove any extra layer between Python and GUI. I want all GUI
elements/data to be directly accessible from Python (without extra
libraries).
Your dicts example is nice, but this approach (and some others) lacks
one important feature: ordering of GUI elements. In XML, the order of
all elements is specified, and with dicts (or with very clean Georg's
model) it is not. (BTW remember topics about ordered dicts...)

ConmfigObj is *another* configuration module that has a nice syntax for
storing data. It will effectively store nested dicts with single items
or lists for values. You access members using the mapping protocol
(ordinary dictionary syntax), but members *are* ordered. (ConfigObj
instances are effectively ordered dictionaries as well.)

You say you don't want an 'extra layer' between your GUI and Python -
but your approach of using XML has the same drawback. Storing your 'GUI
configuration' in a text based format is a nice idea, but you will need
*something* to do the translation.

http://www.voidspace.org.uk/python/configobj.html

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[bruno at modulix]

Fuzzyman wrote:
(snip)

You say you don't want an 'extra layer' between your GUI and Python -
but your approach of using XML has the same drawback. Storing your 'GUI
configuration' in a text based format is a nice idea, but you will need
*something* to do the translation.

Well, if the conf is valid Python, you've already get most of the
'something to do the translation' for free !-)

 

[bruno at modulix]

Bruno: in your original example, how can it be specified that image
should be placed before text? Of course, it *can* be done with one
extra level of wrapping of gui elements in list... did you mean that?

Yes. That's a pretty straightforward translation of the real Python's
object structure:

class Window(...):
def __init__(self):
self._widgets = []

=>

window = {
'widgets' : [],
}

 

[Fuzzyman]

Fuzzyman wrote:
(snip)


Well, if the conf is valid Python, you've already get most of the
'something to do the translation' for free !-)

Except he can't use ordinary dictionaries because they don't preserve
order, which is one of his requirements...

Your trivial example below redone with ConfigObj syntax :

[window]

widgets = , # empty list

Code to read it :

from configobj import ConfigObj
gui_object = ConfigObj(filename)

All thebest,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[bruno at modulix]

Except he can't use ordinary dictionaries because they don't preserve
order, which is one of his requirements...

Except that dict ordering (or lack of) is not a problem here, cf my
other posts about this !-)

 

[Marc 'BlackJack' Rintsch]

The syntax is the same, except for, as I said, JSON's multiline comments.
The semantics do differ, but that has nothing to do with the user's
question, about an alternative to XML for data representation. You
can use "true" or True or "null" or None or whatever semantic values
you want.

You can't use `True`, `False` and `None` in JSON documents. And strings
are delimited by `"` and not `'`. The `\x??` escape is forbidden in
strings and it's not allowed to leave out a leading zero in numbers, nor
is it allowed to start a number with a unary `+`.

Ciao,
Marc 'BlackJack' Rintsch

 

[bearophileHUGS]

Sorry for the late reply, I have some ideas about a possible GUI
toolkit design (that works with one already done like GTK), I'll
probably show them here. In the meantime I can show this one:
http://thinlet.sourceforge.net/home.html

I like it because the way GUIs are defined is quite short.

bye,
Bearophile