468,140 Members | 1,168 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,140 developers. It's quick & easy.

Evil, evil wxPython (and a glimmer of hope)

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.

Feb 16 '06 #1
12 1653
As you just said, wxPython is "...(a simple wrapper for a C++
toolkit)": it is
oriented toward the C++ style/mindset.

Feb 16 '06 #2

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,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/

Feb 16 '06 #3
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(pattern) if p.isdir()]

Feb 16 '06 #4
"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.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.

--
\ "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.id.au/>
Feb 17 '06 #5
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.

Feb 17 '06 #6
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

Feb 17 '06 #7
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.

Feb 17 '06 #8
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.
Feb 17 '06 #9
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. :-)

Feb 17 '06 #10

vi******@gmail.com wrote:
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. :-)


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

Feb 17 '06 #11
Hallöchen!

"Fuzzyman" <fu******@gmail.com> writes:
vi******@gmail.com wrote:
vi******@gmail.com 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.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646
Feb 17 '06 #12
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. ;-)

Feb 17 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by Grant Edwards | last post: by
25 posts views Thread by BJörn Lindqvist | last post: by
12 posts views Thread by Simon John | last post: by
3 posts views Thread by writeson | last post: by
4 posts views Thread by Jive Dadson | last post: by
6 posts views Thread by BartlebyScrivener | last post: by
1 post views Thread by Benjamin | last post: by
2 posts views Thread by ahlongxp | last post: by
1 post views Thread by codemania | last post: by
27 posts views Thread by didacticone | last post: by
1 post views Thread by gcdp | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.