Cute python: [Anygui] Project preview

There is a very interesting [Anygui] project in the Python world that has entered the early stages of development. The [Anygui] project is intended to serve as a low-level API for many major graphics toolkits. Once fully developed, Python programmers can invoke a common [Anygui] function--for example, to create a window--that can be done by the "most appropriate and easy to use" toolbox. On Windows, you can use the Win32 API (or Wxwindows), on MacOS, native calls, BeOS, Bethon on Linux, Tkinter or GTK on the Telnet screen, and N Curses― all of this depends on the software installed and available on the given machine. This article discusses the current development status of [Anygui] and the objectives to be achieved by the project.

Write once and show everywhere!

When Java first appeared many years ago, one of its important commitments was to implement the idea that code "write once, run anywhere." Initially, the main consideration was to embed the Java user interface as an applet into a Web browser. After a while, the independent AWT application becomes a more popular concept. Next, AWT is usually replaced by Swing. Swing becomes a Bean again (built on swing, but with another requirement). In turn, Swing classes are added, truncated, and constantly changing from the Java version.

A very popular joke about Java is, "write once, debug everywhere." At the very least, you can't possibly write a Java application and feel confident that it can run on every user machine in your application-unless you're willing to ask each user to do quite a lot of work to get the Java version and configuration so that they fully conform to your particular application. Whether an application runs depends on the Java version, and even on specific vendors and platforms that install Java Virtual machines (JVMS).

For the most part, scripting languages such as Python, Perl, and TCL are more portable than Java. For example, for most Python scripts, programmers are very confident that scripts sent to multiple users will run correctly and completely consistently on each target machine (there may be a minimum version requirement-This is much simpler and more reliable than Java requirements). Of course, Java in addition to the imperfect portability, it also has many advantages: static input (many people want it), a large class library, excellent documentation, careful design choices. But the attention to those languages is not the topic I'm interested in here.

One place in Python script portability is much worse than Java, which is in the user interface. This is not a problem for a command-line tool. But when you want complex user interaction--specifically for graphical interfaces--―python actually nothing. For all the glitches and glitches, Java does typically provide the basic GUI for Swing and AWT for each platform with a JVM. In contrast, Python does not have any "standard" GUI libraries at all.

Many people say they expect a standard Python GUI. Tkinter comes at this point-it has a stable version of Windows and unix/x Window systems and has a passable MacOS version. But you also need to install TCL and TK on the system, as well as neglected "non-mainstream" platforms such as BeOS and OS/2. Advocates suggest that using some other library/binding will be a better choice (there are many libraries to choose from; see Resources). Each library/binding supports a subset of the desired platform, and most importantly, none of the libraries/bindings are uniformly accepted (therefore, none of them are standard and distributed with the Python distribution). We can't write an application with a user interface, and we can't make sure that the actual user can interoperate with it.

Reconsider the question.

The Java idea creates a standard set of capabilities that each JVM must implement. The Java GUI is based on rules. The Python approach may come from a different angle. Instead of ordering each machine to conform to a certain API, it simply determines what a given machine can do and then starts working from there. The API serves only as a wrapper for the work done by the underlying platform.

Once you think about the problem in Python, Anygui does what you really want to do. Remove its name and instructions from the ANYDBM module, find the "most appropriately available" database backend at run time, Anygui find the most appropriate GUI backend on the system on which its application is running. Anygui emphasizes providing a useful set of interface elements that can work with each backend, and the particular backend may be able to provide a more advanced interface, but Anygui provides a common interface.

When writing this article, Anygui is also an alpha-level project. Anygui has done very well on a target after the set of terminals. But since the goal is to build a (near) generic wrapper, only a subset of the work is clearly not enough. Ultimately, if Anygui achieves its goal, then in every Python distribution, Anygui will be included as a standard Python package, and that makes sense (as is the case with whatever depends on the backend of the system, ANYDBM or XML is included in the Python distribution). Sax). After all, this ensures that every user has it. By the way, Anygui is pure Python; it doesn't need anything in C + + or any other lower-level language (of course, if it works, Anygui should look for some supported GUI libraries).