Evil, evil wxPython (and a glimmer of hope)
viva...@gmail.com
(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.
Pietro Campesato
toolkit)": it is
oriented toward the C++ style/mindset.
snoe
Take a look at dabo, II think they're doing exactly what you're
describing.
http://blog.dabodev.com/
viva...@gmail.com
> 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()]
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.
--
\ "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/>
viva...@gmail.com
> 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.
Fuzzyman
> 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/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,
viva...@gmail.com
> 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
> 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.
viva...@gmail.com
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. :-)
Fuzzyman
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.
Torsten Bronger
"Fuzzyman" <fuzz...@gmail.com> writes:
> viva...@gmail.com wrote:
>
>> viva...@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
Ville Vainio
> 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. ;-)