Evil, evil wxPython (and a glimmer of hope)

[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,n ode):
c = []
nc,cookie = self.GetFirstCh ild(node)
while 1:
info = self.GetItemTex t(nc)
c.append((info, nc))

nc, cookie= self.GetNextChi ld(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("r oot 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.

[Pietro Campesato]

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

[snoe]

vi******@gmail. com wrote:

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,n ode):
c = []
nc,cookie = self.GetFirstCh ild(node)
while 1:
info = self.GetItemTex t(nc)
c.append((info, nc))

nc, cookie= self.GetNextChi ld(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("r oot 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/

[vivainio]

snoe wrote:

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(pa ttern) if p.isdir()]

[Ben Finney]

"vi******@gmail .com" <vi******@gmail .com> writes:

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.or g/labs/dope_on_wax.htm l>
<URL:http://zephyrfalcon.or g/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.

--
\ "We are not gonna be great; we are not gonna be amazing; we are |
`\ gonna be *amazingly* amazing!" -- Zaphod Beeblebrox, _The |
_o__) Hitch-Hiker's Guide To The Galaxy_, Douglas Adams |
Ben Finney <http://www.benfinney.i d.au/>

[vivainio]

Ben Finney wrote:

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/f...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.

[Fuzzyman]

vi******@gmail. com wrote:

Ben Finney wrote:

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/f...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

[vivainio]

Fuzzyman wrote:

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.

[Peter Decker]

On 16 Feb 2006 14:07:36 -0800, vi******@gmail. com <vi******@gmail .com> wrote:

snoe wrote:

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.

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.

--

# p.d.

[vivainio]

vi******@gmail. com wrote:

Fuzzyman wrote:

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.

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. :-)