wxPython syntax

[OKB (not okblacke)]

I've started taking a look at wxPython, and, well, I've noticed
that the syntax needed to code with it is extremely ugly. I am
wondering if there exist any preprocessing tools or clever refactorings
that allow users to write more sane-looking code. In particular, it
seems to me that the structure of the code often does not reflect the
structure of the GUI being designed. For instance, the wxPython wiki
"Getting Started" guide includes this code to set up a file menu with
About and Exit options:

filemenu= wxMenu()
filemenu.Append(ID_ABOUT, "&About","Information about this
program")
filemenu.AppendSeparator()
filemenu.Append(ID_EXIT,"E&xit","Terminate the program")
# Creating the menubar.
menuBar = wxMenuBar()
menuBar.Append(filemenu,"&File")
self.SetMenuBar(menuBar)content.
EVT_MENU(self, ID_ABOUT, self.OnAbout)
EVT_MENU(self, ID_EXIT, self.OnExit)
self.Show(true)
def OnAbout(self,e):
d= wxMessageDialog( self, "A sample editor \n" "in
wxPython","About Sample Editor", wxOK)
d.ShowModal()
d.Destroy()
def OnExit(self,e):
self.Close(true)

Pieces of the code, like "filemenu" and ID_ABOUT and OnAbout, are
confusingly repeated throughout the definition. Doesn't it seem like
there should be some way to structure it so that the interface nesting
"option in menu in frame" is reflected in the code? I want to do
something like this:

menus:
File(wxMenu):
name = "&File"
about(menuOption):
name = "About"
statusText = "Information about this program"
action():
wxMessageDialog(self, "A sample editor. . .")
exit(menuOption):
name = "Exit"
etc. . .

Now, obviously that isn't valid code, but it seems like it might be
possible to get something like by using nested classes and/or functions
(e.g., have it say "class menus:" and then "class file(wxMenu)"). So my
basic questions are:

1) Does anything like this exist (or is anything in development)?
Is there any way to write GUI code in a way that reflects the structure
of the GUI?

2) If not, is it possible?

3) One specific problem is that I can't find a way to get at the
information in nested classes. Does Python provide any way to, say,
take a certain class and loop through all the classes which are defined
as nested classes inside it? Or, more generally, what kind of syntactic
help can be had from Python with regard to creating nested structures
like this?

Any thoughts would be appreciated.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Grant Edwards]

I've started taking a look at wxPython, and, well, I've
noticed that the syntax needed to code with it is extremely
ugly.

Yup -- we just had this discussion a couple weeks ago.

I am wondering if there exist any preprocessing tools or
clever refactorings that allow users to write more
sane-looking code.

wax is one such attempt to wrap wxPython widgets and provide a
cleaner, simpler syntax.

 

[Grant Edwards]

Yup -- we just had this discussion a couple weeks ago.

Google the group for the subject line "Don't understand wxPython ids".

The bottom line is that un-pythonic syntax of wxPython reflects
the un-pythonic syntax of the underlying C++ library. Two of
the fundamental decisions that makes wxWidgets complex and
difficult to work with compared to most other widget sets are

1) Using the "object-ID/event-ID" scheme to hook handlers to
events rather that making handlers attributes of widgets.
It's a more general/powerful scheme, but for small apps
like I write it's just gratuitous complexity.

2) Making the widget hierarchy separate from the layout
hierarchy. Again, it's a more general and powerful way to
do things, but for the small apps I write it's added work
and complexity with no benefit.

 

[OKB (not okblacke)]

The bottom line is that un-pythonic syntax of wxPython reflects
the un-pythonic syntax of the underlying C++ library.

I've noticed this, and I must say it irks me. It seems as though
wxPython is simply providing a way to drop C++ code into a Python
program, which is, needless to say, undesirable. (I mean, Python is
NICE. I use it so I DON'T have to learn ugly C++ stuff.) I don't want
to sound harsh, but why is it like this? I suppose the obvious answer
is "it's easier to do it that way", but it still seems like it would be
nice if there were a real PYTHON GUI library.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Roger Binns]

but it still seems like it would be
nice if there were a real PYTHON GUI library.

It is all open source - feel free to write your own or collaborate with
other people.

In my experience of writing gui in several different programming
languages and platforms, it is *always* tedious and long winded.
(The only exception is immature or incomplete toolkits in the
first few years of their existence).

One thing I recommend you do is try to move the actual construction
of the gui interface out of your code. Use something like XRC
which describes the interface in XML.

You will still need to hook the various interface widgets/events
into code, but you will be able to do that in a way that makes
sense for the program you are writing.

Roger

 

[Andrei]

I've started taking a look at wxPython, and, well, I've noticed
that the syntax needed to code with it is extremely ugly. I am
wondering if there exist any preprocessing tools or clever refactorings
that allow users to write more sane-looking code. In particular, it

wax is supposed to be more Pythonic, but I haven't used it (yet).

seems to me that the structure of the code often does not reflect the
structure of the GUI being designed. For instance, the wxPython wiki
"Getting Started" guide includes this code to set up a file menu with
About and Exit options:

<snip>

You're right, this kind of code is ugly. Fortunately you don't *have to* write
any of it, since you can use one of the design tools available to generate all
the ugly stuff. You'll still have to live with lots of Get... and Set... methods
instead of just plain properties, but that's bearable. My fav. is wxGlade.

Pieces of the code, like "filemenu" and ID_ABOUT and OnAbout, are
confusingly repeated throughout the definition. Doesn't it seem like

wxGlade won't make the id's go away though. wax will.

Yours,

Andrei

 

[David Fraser]

menus:
File(wxMenu):
name = "&File"
about(menuOption):
name = "About"
statusText = "Information about this program"
action():
wxMessageDialog(self, "A sample editor. . .")
exit(menuOption):
name = "Exit"
etc. . .

Now, obviously that isn't valid code, but it seems like it might be
possible to get something like by using nested classes and/or functions
(e.g., have it say "class menus:" and then "class file(wxMenu)"). So my
basic questions are:

This is great - it's almost exactly like the syntax I have in mind for
declaring wx GUIs.
My syntax idea is more like this:

wxMenu File:
name = "&File"
menuOption about:
name = "About"
statusText = "Information about this program"
menuOption exit:
...

Except note that I've left the code bits out.
This idea follows from the following principles & ideas:

- The best way to define a GUI is with declarative language
- XML is great but not as nice to look at as Python-ish syntax
- Hierarchical definitions are done like they are in Python

I think wx would be easier to use if a syntax like the above were
available which still required you to do all your programming in
standard python. So for example the above section could be in a separate
file or in a string within your code.

The reason I avoided including code is it then means this doesn't become
a mess when lots of code is added, and the parser doesn't have to
understand the whole Python syntax. The question is, how to bind to the
code... I would like an approach like this:

MenuDeclaration = """ ... """ # put the above string in here...
MenuResource = wxResourceParser.Parse(MenuDeclaration)

class FileMenu(MenuResource):
def OnAbout(self, event):
# put the code here
def OnExit(self, event):
# put the code here

So the actual class derives from the resource generated from parsing the
declaration.

Then there could be all kinds of debates as to binding names / events
automatically or doing it manually.

Anyway I might actually get this working ; any comments appreciated

David

 

[OKB (not okblacke)]

MenuDeclaration = """ ... """ # put the above string in here...
MenuResource = wxResourceParser.Parse(MenuDeclaration)

class FileMenu(MenuResource):
def OnAbout(self, event):
# put the code here
def OnExit(self, event):
# put the code here

This is a cool idea. I like the looks of it. One worry I have,
though, is that with the code outside the hierarchical definition
there'll still be confusion about the organization. What if you have a
menu bar as well as some other widgets, or submenus? Also, what about
things like listboxes, where you want the list elements to be determined
programmatically? Various interrelationships might exist between the
GUI's appearance and its content, which could be difficult to express if
the layout were being specified with some static text. I'm not sure how
best to handle this, but I think it's something to think about.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[David Fraser]

David Fraser wrote:




This is a cool idea. I like the looks of it. One worry I have,
though, is that with the code outside the hierarchical definition
there'll still be confusion about the organization. What if you have a
menu bar as well as some other widgets, or submenus? Also, what about
things like listboxes, where you want the list elements to be determined
programmatically? Various interrelationships might exist between the
GUI's appearance and its content, which could be difficult to express if
the layout were being specified with some static text. I'm not sure how
best to handle this, but I think it's something to think about.

The idea of this approach is that you use the resource string to define
the simple stuff and then do the rest in code. For example, define a
list box but no elements, than add them in the initializer. Because the
Resource is used as a base class for the class you are declaring, you
can call its initializer from the derived classes initializer, and then
make any changes that are desired (including adding custom widgets or
even doing fancy things with sizers).
One of the main things that would need to be addressed is how sizers and
layout could be defined using this approach

David

 

[John Taylor]

One of the main things that would need to be addressed is how sizers and
layout could be defined using this approach

David

The easiest (and therefore best, imho) way that I have ever seen to
manage widget layout is in Java's RelativeLayout. See
http://www.onjava.com/pub/a/onjava/2002/09/18/relativelayout.html
Within this, layout is controlled by a xml file.

Does anyone know if any of the python gui toolkits have something
similar to this?
Not the xml file, but the methodology itself.

-John

 

[David Fraser]

The easiest (and therefore best, imho) way that I have ever seen to
manage widget layout is in Java's RelativeLayout. See
http://www.onjava.com/pub/a/onjava/2002/09/18/relativelayout.html
Within this, layout is controlled by a xml file.

Thanks for the link, interesting article.

Does anyone know if any of the python gui toolkits have something
similar to this?
Not the xml file, but the methodology itself.

Not sure. I'm sure you could create a similar methodology layout class
for wxPython though...

David

 

[John Taylor]

Thanks for the link, interesting article.


Not sure. I'm sure you could create a similar methodology layout class
for wxPython though...

David

I forgot to mention that I got this up & running in Jython without too
much trouble. Jython can't use CPython's external libraries (on at
least Windows platforms). So if I wanted to use ldap and/or mysql, I
would have to code those sections in Java. By this point, it kind of
defeated the whole point as it would have been better to have coded
the whole thing in Java instead.

I could have used a client/server model and ran the GUI in Java which
would communicate to a python based server. I never did get around to
trying this approach, however.

-John