Brian Blais <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
[...] > Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). > In my view, this is *exactly* what python needs, and its not > being maintained anymore as far as I can tell. What I like > about it is: > > 1) it is small...I can include the entire wax distribution in my > app with only a 780k > footprint. > 2) it is a very thin layer on wx, so when something doesn't > quite work, I can immediately fall back onto wx, mixing and > matching wax and wx objects. it's just that the wax objects > have more pythonic calling and use properties > > > Is there a reason that the port of wxPython doesn't include wax, > or something similar? It would seem pretty straightforward, > when porting the wx to Python, to simply include such a wrapper. > I wish I were more clever, and had more time, to take over the > maintenance of wax because I think it is the most > straightforward, practical, and pythonic solution out there. > > > Do others think like me here? > I certainly do. Whether wax is the particular solution or not, something very like it should be. Something like this was tried at one time (Anygui) and the general consensus seems to be that it doesn't work as an approach because the packages are too different. I think that it's past time to revisit that conclusion. It would be very useful to a user of the Language we call Python to be able to write GUI code without regard to the back-end package. If there were a standard Python GUI API (call it the PGA, say) that be the target for app developers, they wouldn't have to worry about the back end. The PGA would have to be flexible enough to handle incompatibilities among the various approaches to displaying widgets and text. In order for that to happen, some kind of meeting of minds (among those who now deal with the murky middle between gui packages and python) would have to take place. A standard would have to be hammered out and then used. The standard would have to allow for generic calls for tasks that any reasonable GUI would have to handle. It would also have to provide for system-specific calls for those things that each package might require uniquely. The interface to the system- specific stuff should itself be the same regardless of the back end. What I mean by this is that, where wax's limitations are overcome by dropping to wx directly, there should instead by a PGA winsys() call that permits passing command strings, values, or whatever in a dict-like object that would be permit the pga2wx interface to create the specific calls it needs. When the back end changes to Qt, the pga2Qt interface would make the translation instead. The code from the app programmer should not have to change, except maybe to add another item or items to the winsys dict. I also think there should something similar for an interface for Python database access (PDBA). Anydb might not be the solution, but it could be. It would take cleverness (which abounds in the Python community), determination (which may not be in such abundance) and project coordination for either of these projects to come to fruition. A summer of code kind of thing would provide a good initial push, and some sprints could move things along at a good clip. Wax, anygui, and anydb seem to be acceptable starting points, but the key thing is to get agreement from key players (like the developers of wxPython, dabo, PythonCard, and so on) to agree that this is a good direction to go in, and to try to work out the requirements for a flexible PGA and PDBA. I'm sure that the approach could produce usable results in short order, and then attack the remaining limitations over time. Do I think this is going to happen? No. There are two overlapping things we call Python: the Language and the Package. The Language comes from Guido and a few others, but the Package comes from many sources, mostly volunteers. The GUI interfaces come from many such sources, each with a different view of what constitutes a good Pythonic interface. Having put a lot of time and effort into getting their version up and running, they're not about to change for some abstract reason, but nonetheless, I do believe that the Language of Python should have a GUI API defined, and that the Package of Python should accommodate to that. Unless that happens, we'll see more of what we now see: continual questions about what is the best GUI or the best Database. Because once you start building an app, you commit to the syntax of the package and you are no longer (in my view) coding in Python, but in that subset that includes the GUI Package of your choice. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
