Vadim Zeitlin <zeitlin at seth.lpthe.jussieu.fr> wrote: > But, to return to the main subject: I don't belive that you can do it. Even > with unlimited amount of free time (a strong assumption) it would still be > difficult to do it without creating a 100Mb monster library collapsing under > its own weight and complexity. There's also the most common denominator problem. It's easy to code something up that wraps the buttons and text fields of all toolkits, since all toolkits have those. That's what Sun has done with AWT, basically. However, if you want to have all the great extensions that every toolkit provides, then you'll have to write emulation code for the missing bits, _if_ you're set on using what's already available. That's the position of wxWindows. Correct me if I'm wrong, but I rather had the impression that all the really interesting, high-level widgets wxWindows offers are custom-coded for wxWindows, like the html-widget. Or, and that's the approach Qt takes, and tk took before it started using native widgets (if I remember correctly), you can write a portable toolkit - portable in that it compiles on every platform that has primitives for drawLine and putPixel, and make it emulate the platform look and feel. Swing takes this route, too. It's quite doable, and can lead to good results (Qt looks and feels just native), or to bad results (Swing), but it can work. See also Trolltech's paper on the subject: ftp://ftp.trolltech.com/qt/pdf/whitepaper.pdf. Covering all existing API's with a new API is basically a pipe-dream, that doesn't solve any problem. It merely adds surfeit to an already existing embarrasment of choice, and will never make the lower API disappear... Trying to get everyone to use the same uber-API is a political endeavor, not a technical. People chose one API over another because they like the style of coding better, or because of its cross-platform availability, not because it keeps users of all other API's contented. Personally, I like choice - I've carefully evaluated all gui toolkits before choosing one: PyQt, PythonQt, tkInter, wxWindows, wxGTK, Amulet, Foxpy, pyFLTK... Not the MFC bindings of Python, though - I didn't need to, having been a Windows programmer in a prior life ;-). -- Boudewijn Rempt | http://www.valdyas.org | Christos Voskrese!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4