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