Wheel-reinvention with Python

[Paul McNett]

Torsten Bronger wrote:

> Terry Hancock <hancock at anansispaceworks.com> writes:

>>I know I'm diving into this conversation late, and I haven't read
>>the whole thread, but has someone yet mentioned the "anygui"
>>project?  This has stalled, but it was IMHO a good idea.

> I don't know exactly why this project died, but I'd start with a
> Pythonic variant of wxPython.  I've read many discussions about the
> people who didn't like the wxPython's C++ style, so there are
> chances to get fellow developers and users.  You must reach the
> critical mass quickly in order to get a survivable project, and
> being not too far away from an existing one is a good stating point.
> 
> Possibly Dabo manages such a thing.

Dabo does indeed begin to manage a pythonic wrapper to wxPython. When we 
originally began Dabo, we envisioned wrapping all the major UI toolkits, 
such as Tkinter, PyQt, wxPython, curses, and even http. You would define 
your subclasses of the Dabo base widgets, and then at app startup you'd 
specify which UI library you wanted to use. As long as your own code was 
clean of UI-library-specific references your UI could render on any 
supported library.

I got some minimal proof-of-concept work done about a year ago, to show 
that the same code could render on wxPython as well as on Tkinter. But, 
unless we get a lot more help, developer or financial, I think it's safe 
to say Dabo wraps wxPython, and that's it.

Now, that was only one part of the original Dabo vision, and the other 
parts of the vision may actually add too much baggage and bloat for 
people just interested in the UI aspect. Dabo also provides an 
Application object, a database layer, and a business object layer. Ed 
and I have discussed the possibility of ripping out the UI layer and 
putting it into a completely separate project for the purpose of getting 
more wxPython users interested. It wouldn't be all that hard to do, 
because we've kept all the UI code separate from the the other stuff by 
design.

If we ever get to the "critical mass", we can start adding wrappers for 
other libraries, but this vision is always going to be limited by a 
"lowest common denominator" factor. But one of the other things we've 
done with Dabo is keep access to the base UI-library functionality if 
needed. IOW, say you are developing an app that you know will always use 
wxPython. For the most part, you will be able to use pure-Dabo 
properties, events, and methods to implement your UI. But, perhaps there 
is something more low-level that you need to do, such as using a DC to 
draw something on top of a widget, and Dabo doesn't wrap that. Dabo's UI 
classes are mixins to wxPython's, and you could just import wx manually 
to get access to the wx namespace and do whatever you want. While this 
goes against Dabo's vision on an idealistic level, it satisfies your 
needs at a practical level. You can benefit from Dabo's ease of use 80% 
of the time, and resort to doing lower-level stuff only when needed.

As far as anygui goes, we only became aware of it after significant work 
had already gone into Dabo. I have looked at it and I think there may be 
possibility for some mindshare between the projects, but it is, alas, 
always easier to reinvent the wheel yourself than to try to design by 
committee.

-- 
Paul McNett
http://paulmcnett.com