Timothy Grant wrote: > Hi folks, > > I have seen the GUI wars here, and have for the most part > ignored them. I am now in a situation where I need input. DISCLAIMER: I have never used any of the Python GUI toolkits. Which toolkit to use? Personally, I don't care. This should not be taken as me being callous. I mean it in a deeper level, as in "What difference is there, really, between the toolkits?" For a simple app, probably none (at least functionally). Open window, pop dialog box, hook a function to "OnClose" signal; you're doing pretty much the same thing. So for simple apps, "Which toolkit?" is really a false choice. Complicating things is that toolkits are not nessassarily portable: someone mentioned that Qt is free on Linux, but you have to shell out money for the Windows port. Even if they are availible for all platforms, if someone doesn't have that toolkit installed, they have to install it before they can use your program. This may not be an issue for major programs, but people will think twice about using a (small) program if, in order to use it, they need to hunt down the toolkit package. In all, it's possible that people (especially newbies) may throw up their hands and say "forget it". (And then jump ship to Visual Basic because you can easily create "actual" programs instead of "inferior" DOS mode programs.) So why can't we make programs that can run under any windowing toolkit? My idea is to take a lesson from the Pythoneers working with databases: The database-SIG came up with a Python Database API which all database modules are encouraged to implement. Nothing strictly prohibits modules from implementing additional features, but all the basic functions are the same, thus it should be minimal to swap one database implementation for another. The modules that come "batteries included" also include the 'anydbm' module, which can determine at runtime which DBM-style database system to use, transparent to the programmer using it. What I envision is that a programmer with simple GUI needs would program in a generic API, and the program would dynamically determine which toolkits are available, and use the appropriate one. One could even specify your preferences by, for example, passing a list: ['Tk','wxWindows',None]. Any thoughts on whether something like that could be made to work? Note that there is nothing here prohibiting non-generic services (e.g. items provided by wxWindows that Tk does not support), or also providing the "legacy" API.
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