Considerations when choosing a GUI package

As we have seen, there are quite a few ways to build a GUI in Python and in some cases a choice is difficult. How, for instance, can you choose among Tk, wxWindows, FLTK or FOX if you do not have knowledge or experience in them? Well, before you make a choice you should have a look at each of them in any case. And you should check the following issues:

1. The number of widgets. Well, if they are ugly or unnecessarily numerous, you will not be satisfied. But a diversity of good looking and functional widgets will help you design a good interface, especially if you are not a GUI designer.
2. Look. It is very important nowadays to allow an application to look exactly according to the current theme of the operationg system, including widgets that do not exist on a particular OS.
3. For some projects it may also be important to change the look-&-feel of the application when changing the theme of the OS.
4. It is also 'in' to be able to create your own look-&-feel
5. It is important to be able to create your own components.
   If you need, see whether you can create your own windows or use transparent screen areas.
6. See if widgets provide transparency and layering.
7. See if it is possible to locate widgets both absolutely and relatively.
8. See if zooming is supported. I do not know of any GUI library for Python that does
9. See if the image formats you work with are supported. I recommend to check out PNG because it is compressed, transparent, interlacing, animateable and supported by the Internet Explorer.
10. Look at the geometry capabilities. It may sound weird but the most important geometric figure is a dot. Some packages provide you with lines, circles and what not but when you wish to draw whatever you wish, you often need just a dot :). It may be specially true if you wish to go into charting.
11. Text and language issues:
• Internationalization:
• Unicode
• Locales. Locale is a convenient tool bacause besides the language you can specify the time, monetary and other options.
• Some GUI libraries offer you good text components in which you can show formatted text.
  Some even go further and allow you show text directly in the common formats (HTML, rtf, pdf, doc)
12. Grid.
• Ability to use any other widget as a cell.
• Speed. Grids can work slowly with large data chunks.
13. Cross platform compatibility may be important to you. There are three issues:
• Does it cover all the platforms you need
• Does it really look fine on all platforms:
• when you do not define a specific look-&-feel and your application uses the OS l&f
• when you use a certain l&f
• You write one code and do not go into the OS specifics
14. Separation between data and presentation. It is particularly convenient when your GUI is based on some changing data.
15. Check the license
16. How popular the library is. The more popular it is the more chances there are that it will not vanish tomorrow morning. For example, Tk IS popular. wxWindows is also popular because many people out there consider it to be better than Tk. But who can compare with GTK+ which is a part of such projects as GNOME and GIMP?!
17. Who stands behind the library. It is very important to know that the development of the library you use will continue for as long as you need.
18. Open source or proprietary? It is good when a rich company stands behind a libary. But they can grab you by the ... .
    Open source is theoretically unreliable from many aspects but in practice it is the best because the best brains stand behind it.
19. There are also other, I call them traditional, considerations such as speed, memory use, multithreading and many others but the packages listed above are good. In any case, if you know of some theoretical problem that may come up, test it. For example if you are writing an image browser, load a hundred PSD thumbs into a slider and see if it stands the pressure.

Comparison chart of all the packages listed here - UNDER CONSTRUCTION
It is going to be a table with the following paramaters for comparison:

1. Shell: whether it is performed as you type (like Python, Tk, DOS etc)
2. Widgets: number and usefulness
3. Native fook-&-leel issues
4. Realtime theme change
5. Custom l&f
6. Transparent top level windows
7. Absolute layout
8. Relative layout
9. Supported image formats
10. Localization
11. Unicode and internationalization
12. Data structures and graphical widget for supporting formatted text
13. Text Formats: HTML, RTF, XML etc
14. Grid support
15. Platforms
16. View-Model Architecture
17. License type
18. Used in Longliving Projects (QT in KDE, GTK in GIMP etc)
19. Who is the developer

Creating your own GUI package
The most ideal situation would be if Python had at least the most primitive commands for windowing systems.
The problem is that there are at least three differently built systems: Windows, X, Mac and why learn how to program them if someone else already did. That's what I think thought Guido van Rossum the Father of Python. He began with the Tk GUI library. As this page shows, many more GUI libraries followed. But how?! Python has a C extention mechanism. So, if some C++ GUI library has objects: Window, Button, Canvas it is possible to call these objects from Python. This leads to the situation when each of the numerous C GUI libraries must have its own wrapper in Python. But don't we live in the crosseverything compatibility age?! Wouldn't it be great to write one GUI package in Python and let developers decide what C GUI libraries they wish to use underneath. And this, in turn, leads to the AnyGUI situation when AnyGUI.Window is implemented by PyToSomeCLibWrapper.Window. In this respect AnyGUI is just like Java AWT. For those of you who do not know, such a solution did not work for Java.
The next stage of Python GUI packages should be the Swing stage of Java when there is preferably but not necessarily one native object that does all the drawing and all the actual widgets should be drawn dot by dot in Python. For example a Button object of such a package would have a draw method whose code would be a dot by dot, line by line description of the button and when it's time to show a GUI on the screen, one native object would draw it. In this case it is also possible to use the core of the already existing C GUI libraries but the quality of GUI programing in Python would climb another level just as it did in Java. Of course there will be problems too. The major problem is the bulk of memory such code would occupy and the result of it can be low speed. But Java overcame it by good design, VM speed and the speed of the present day hardware.
An example of such approach to Python GUI packages is the above mentioned Python GUI package.
It is important for me to note that I do not criticize the existing GUI wrappers. First of all, it is really better not to insert graphic commands into the interpreter if there are ready means. Second, Python is, hopefully, unpoliticized language and it gives access to the toolkit of your choice.
What concerns AnyGUI...they should have learned from AWT on the one hand, and it is still a good intermediate means.
What I think about the future... I think that either Python GUI will prevail, or AnyGUI will be rearchitectured to resemble Python GUI, or someone will develop something like Python GUI. I also think it's a pity to waste to for development of such packages as Tix. Tix a either politics or the result of the weak character of those who are ready to put up with the defaultness of Tk.