Evil, evil wxPython (and a glimmer of hope)

Discussion in 'Python' started by vivainio@gmail.com, Feb 16, 2006.

  1. Guest

    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, 2006
    #1
    1. Advertising

  2. As you just said, wxPython is "...(a simple wrapper for a C++
    toolkit)": it is
    oriented toward the C++ style/mindset.
    Pietro Campesato, Feb 16, 2006
    #2
    1. Advertising

  3. snoe Guest

    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/
    snoe, Feb 16, 2006
    #3
  4. Guest

    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, 2006
    #4
  5. Ben Finney Guest

    "" <> 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/>
    Ben Finney, Feb 17, 2006
    #5
  6. Guest

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

    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, 2006
    #6
  7. Fuzzyman Guest

    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/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
    Fuzzyman, Feb 17, 2006
    #7
  8. Guest

    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, 2006
    #8
  9. Peter Decker Guest

    On 16 Feb 2006 14:07:36 -0800, <> 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.
    Peter Decker, Feb 17, 2006
    #9
  10. Guest

    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, 2006
    #10
  11. Fuzzyman Guest

    wrote:
    > 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
    Fuzzyman, Feb 17, 2006
    #11
  12. Hallöchen!

    "Fuzzyman" <> writes:

    > wrote:
    >
    >> 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
    Torsten Bronger, Feb 17, 2006
    #12
  13. Ville Vainio Guest

    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. ;-)
    Ville Vainio, Feb 17, 2006
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anand
    Replies:
    1
    Views:
    354
    Cliff Wells
    Jul 23, 2003
  2. ulysses
    Replies:
    4
    Views:
    764
    Werner Schiendl
    Oct 22, 2003
  3. Chris Marshall

    seek and __DATA__ not behaving how I would hope

    Chris Marshall, May 17, 2005, in forum: Perl Misc
    Replies:
    8
    Views:
    124
    Tad McClellan
    Jun 4, 2005
  4. PerlFAQ Server
    Replies:
    0
    Views:
    94
    PerlFAQ Server
    Feb 25, 2011
  5. CM
    Replies:
    9
    Views:
    113
    Ethan Furman
    Aug 3, 2013
Loading...

Share This Page