Evil, evil wxPython (and a glimmer of hope)

V

vivainio

I rarely do GUIs, and reminded myself today why that is the case
(simply, it's not fun).

I implemented a simple TreeCtrl, and had to implement my own 'children'
method, of all things!

Here it is:

def children(self,node):
c = []
nc,cookie = self.GetFirstChild(node)
while 1:
info = self.GetItemText(nc)
c.append((info,nc))

nc, cookie= self.GetNextChild(node,cookie)
if not nc.IsOk():
break

return c


And it even fails with zero children. This is as unpythonic as it gets.

However, it should be pretty easy to write small wrapper over the
wxPython api. I'm thinking of wrapping or injecting additional methods
to TreeCtrl that start with lowercase letters and return something
sensible, with reasonable methods. Something like:

root = self.AddRoot("root dir") # root is normal wx TreeCtrl root
tree = EasyWx(root) # now tree is our wrapped, more "fun" root
for c in tree.children():
print c.name

# etc. etc.

This is a bit like Brian Orendorff's "path" module that turns something
low level to something you can use easily, without throwing you into a
world of "frameworks", toolkits and whatnot. I can see there are things
like Wax or PythonCard, but they are still too "frameworky", and you
don't use them to extend wxPython, you use *them* and they use
wxPython. I'd basically like to rely on something that is there for the
long haul (plain wxPython API) but only use convenience wrappers *on my
own initiative*, as it seems convenient. Just like I'd use the "path"
module.

wxPython is great as it is (a simple wrapper for a C++ toolkit) and the
basic design is ok & proven, I'm just too lazy to use it in its current
form.
 
P

Pietro Campesato

As you just said, wxPython is "...(a simple wrapper for a C++
toolkit)": it is
oriented toward the C++ style/mindset.
 
S

snoe

I rarely do GUIs, and reminded myself today why that is the case
(simply, it's not fun).

I implemented a simple TreeCtrl, and had to implement my own 'children'
method, of all things!

Here it is:

def children(self,node):
c = []
nc,cookie = self.GetFirstChild(node)
while 1:
info = self.GetItemText(nc)
c.append((info,nc))

nc, cookie= self.GetNextChild(node,cookie)
if not nc.IsOk():
break

return c


And it even fails with zero children. This is as unpythonic as it gets.

However, it should be pretty easy to write small wrapper over the
wxPython api. I'm thinking of wrapping or injecting additional methods
to TreeCtrl that start with lowercase letters and return something
sensible, with reasonable methods. Something like:

root = self.AddRoot("root dir") # root is normal wx TreeCtrl root
tree = EasyWx(root) # now tree is our wrapped, more "fun" root
for c in tree.children():
print c.name

# etc. etc.

This is a bit like Brian Orendorff's "path" module that turns something
low level to something you can use easily, without throwing you into a
world of "frameworks", toolkits and whatnot. I can see there are things
like Wax or PythonCard, but they are still too "frameworky", and you
don't use them to extend wxPython, you use *them* and they use
wxPython. I'd basically like to rely on something that is there for the
long haul (plain wxPython API) but only use convenience wrappers *on my
own initiative*, as it seems convenient. Just like I'd use the "path"
module.

wxPython is great as it is (a simple wrapper for a C++ toolkit) and the
basic design is ok & proven, I'm just too lazy to use it in its current
form.

Take a look at dabo, II think they're doing exactly what you're
describing.
http://blog.dabodev.com/
 
V

vivainio

snoe said:
Take a look at dabo, II think they're doing exactly what you're
describing.
http://blog.dabodev.com/

Dabo appear to be doing way more than what I want, with database access
etc.

My ideal module, when implemented, would be extremely small as far as
the size of code goes. I'm using path.py as an example:

http://www.jorendorff.com/articles/python/path/path.py

def dirs(self, pattern=None):
""" D.dirs() -> List of this directory's subdirectories.
"""
return [p for p in self.listdir(pattern) if p.isdir()]
 
B

Ben Finney

I rarely do GUIs, and reminded myself today why that is the case
(simply, it's not fun).

Programming C++ in Python isn't much fun, true.
However, it should be pretty easy to write small wrapper over the
wxPython api.
[...]
wxPython is great as it is (a simple wrapper for a C++ toolkit) and the
basic design is ok & proven, I'm just too lazy to use it in its current
form.

Fortunately, you're not alone in that thought. The wxPython project's
explicit goal is to make wxPython feel as much like wxWidgets as
feasible.

For those that want wxPython to feel more like Python than C++, Hans
Nowak started the 'wax' wrapper:

"Simply put, Wax is a GUI toolkit. It sits on top of wxPython,
removing some of the low-level aspects of that GUI, and adding
some useful abstractions.

The goal is that Wax should be easier to use than wxPython, but
just as feature-rich. Maybe even more so.

The actual situation is different. Frankly, I don't have the time
to work on this project very much. That's why I only add new
features when I need them. Some of my other projects (Firedrop,
Sourcery, etc) use Wax, so over time, when I need more controls, I
add them. On the other hand, a subset of controls is there, and is
usable."

<URL:http://zephyrfalcon.org/labs/dope_on_wax.html>
<URL:http://zephyrfalcon.org/labs/wax.html>

The web content is a bit sparse; fortunately the code has seen more
love than the web pages. Wax was the focus of a couple of Google
"Summer of Code" projects, and new life seems to have been gained as a
result.
 
V

vivainio

Ben said:
The web content is a bit sparse; fortunately the code has seen more
love than the web pages. Wax was the focus of a couple of Google
"Summer of Code" projects, and new life seems to have been gained as a
result.

I'm glad to hear that, however, I just took a look at the mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_id=9696120&forum_id=44351

"""
I am going to take a break from blogging and my personal
projects. This includes Wax. In other words, Wax development will be
on hold for a while. During this time, I might still address urgent
bugs and such, but I don't plan to add new features.
"""

Things like this raise a bit of concern about the survivability of the
project. I wouldn't mind if it was a relatively independent component
but it *is* one that is heavily dependent on wxPython...

Also, I have some issues with the design (I don't know how misguided
they may in fact be, as you can see I'm a complete wx newbie). I'd like
the wax classes to be mixins instead of superclasses, so I could just
add them to the inheritance hierarchy if I needed the features... then,
if wax suddenly went belly-up, I could just remove the mixins and
reimplement the parts that use those, yielding a plain wxpython app.
The method names, also, could be more_pythonic() so I could easily tell
wax stuff from wx stuff. This would be insane if we were talking about
a "standard" windowing system of some kind, but we have to recognize
that we are dealing with volatile third party code here.
 
F

Fuzzyman

I'm glad to hear that, however, I just took a look at the mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_id=9696120&forum_id=44351

"""
I am going to take a break from blogging and my personal
projects. This includes Wax. In other words, Wax development will be
on hold for a while. During this time, I might still address urgent
bugs and such, but I don't plan to add new features.
"""

Things like this raise a bit of concern about the survivability of the
project. I wouldn't mind if it was a relatively independent component
but it *is* one that is heavily dependent on wxPython...

Wax is certainly currently usable and not at all unstable. It has a
small userbase, but it is used. I'm about to start a couple of projects
with it.

The code is relatively simple - so it would be easy to maintain the
parts you use if that was necessary. Certainly easier than duplicating
it yourself from scratch. :)

Once you start using Wax, it really is simple and friendly.

All the best,


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

vivainio

Fuzzyman said:
The code is relatively simple - so it would be easy to maintain the
parts you use if that was necessary. Certainly easier than duplicating
it yourself from scratch. :)

Sounds convincing, I'll give it a shot after all.
 
P

Peter Decker

Dabo appear to be doing way more than what I want, with database access
etc.

That was my first impression, too, but I tried it anyway. Turns out
that you can easily use just the dabo.ui module without ever having to
work with the database stuff.
 
V

vivainio

Sounds convincing, I'll give it a shot after all.

Ok, after brief eyeballing & experimenting, it appears that Wax is just
what I was looking for. The code is simple, concise and trivially
understandable, the level of wrapping seems about right, and examples
are helpful.

I'm glad I came whining about this in c.l.py instead of sucking it up
or switching toolkits altogether. :)
 
F

Fuzzyman

Ok, after brief eyeballing & experimenting, it appears that Wax is just
what I was looking for. The code is simple, concise and trivially
understandable, the level of wrapping seems about right, and examples
are helpful.

I'm glad I came whining about this in c.l.py instead of sucking it up
or switching toolkits altogether. :)

That's good news. I'm about to start using Wax on a couple of
small(ish) projects - so it's nice to know about other users.

All the best,

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

Torsten Bronger

Hallöchen!

Fuzzyman said:
(e-mail address removed) wrote:

[...]

Ok, after brief eyeballing & experimenting, it appears that Wax
is just what I was looking for. The code is simple, concise and
trivially understandable, the level of wrapping seems about
right, and examples are helpful.

[...]

That's good news. I'm about to start using Wax on a couple of
small(ish) projects - so it's nice to know about other users.

Has Wax exceeded the critical mass so that one can be quite certain
that it will still be maintained, say, next year? (Sincere question
since I don't know.)

Tschö,
Torsten.
 
V

Ville Vainio

Torsten Bronger wrote:

Has Wax exceeded the critical mass so that one can be quite certain
that it will still be maintained, say, next year? (Sincere question
since I don't know.)

I was a bit worried about this myself, but after browsing the source I
have to say I'm not terribly so anymore. It's a relatively thin wrapper
over wxPython so you are *almost* using wxPython, but w/o a lot of the
pain & horror, and if Hans Nowak stopped paying attention to it the
maintenance tab could be picked up by someone else rather easily. Also,
wxPython 2.6 is a relatively recent arrival and it's supported, so the
next "breakage point" is relatively far away.

Frankly, I think the time saved by coding for Wax could even exceed the
hypothetical time wasted (in case Wax were discontinued) porting a
finished Wax-using product over to use straight wxPython.

Using Wax (and occasionally peeking at the source) also seems to be a
nice way to learn straight wxPython without being immersed in all the
grossness at once. ;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top