On 7/30/05, Torsten Bronger <[EMAIL PROTECTED]> wrote: > I'm aware of it (and there is Wax and maybe a third one). Actually > it illustrates my point quite well: These projects are small and > instable (Dabo has a developer basis of very few people, Wax has > only one); they are even worse documented; they add another layer > which slows down and requires the end-user to install another > package; they force you to test even more GUI approaches.
Well, wxPython itself is largely the work of a single person, but I doubt that many consider that a reason to avoid it. As far as your comment about 'slowing down' the app, I've found that Dabo and pure-wxPython apps run indistinguishably. Perhaps there are some microseconds of extra processing, but I sure haven't noticed it. And I don't think that the comment about installing another package is fair; *anything* outside of the standard distribution requires that, and Dabo is no more difficult than copying to site-packages. I do agree about the documentation aspect of Dabo, though. The authors have put together some basic stuff to get you started, but have chosen to focus their time on continued development for the time being. But having said that, I found that Dabo uses a very consistent syntax, and was no more difficult to pick up than Python itself. With wxPython, I constantly had to refer to the docs, as every class did things slightly differently. For example, many controls have some text associated with them. Depending on the control, you need to call SetText(), SetLabel(), SetBitmapLabel(), SetTitle(), etc. Dabo wrapped all of these controls so that the identifying text for each is controlled by a single property: Caption. In any Dabo control, executing ctl.Caption="Something" will change its associated text. This sort of consistency removes the need to constantly refer to documentation in order to write your code. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
