[EMAIL PROTECTED] 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/
--
http://mail.python.org/mailman/listinfo/python-list
