Generic GUI Wrapper For Python

An Anonymous Coward writes "IBM is working on a generic GUI wrapper to allow Python developers to write cross-platform GUIs. The anygui project will expose a common set of functions to the programmer and choose which backend gui toolkit to use for the given platform: TK, WIN32, GTK, Bethon, etc. Currently the software is in an alpha stage. The article also has some example code." Update: 10/27 23:53 GMT by T : Magnus Lie Hetland wrote to point out that though this article is hosted at IBM, "Anygui has nothing to do with IBM. It is, in fact, an independent Open Source project currently hosted at SourceForge."

Comments

WxPython

[redcliffe]

What's wrong with WxPython? I've seen software on Linux and Windows that uses that. What is the difference between WxPython and IBM's one?

David

random Java flaming again

[mj6798]

Mertz writes: A popular joke about Java is that it is "write once, debug everywhere."

Pretty much all the portability problems with AWT came from the use of native widgets. So, why is Mertz going to repeat the same mistake in his implementation? In fact, it looks like he is going to work hard to make things worse by exposing different APIs on different platforms.

There are a couple of good cross-platform GUIs for Python: FLTK with Python bindings, Fox with Python bindings, and wxWindows (universal or native) with Python bindings. Mertz's project seems like it recreates something whose functionality already exists--a typical case of N.I.H.

Re:random Java flaming again

[burtonator]

Pretty much all the portability problems with AWT came from the use of native widgets. So, why is Mertz going to repeat the same mistake in his implementation? In fact, it looks like he is going to work hard to make things worse by exposing different APIs on different platforms.

The portability problems did come from AWT but not from the use of native widgets.

The problems arose because SUN kept the Java Development Kit proprietary and refused to fix any bugs in the system.

I mean AWT still uses Motif on UNIX machines (even to this day)? Motif is very different from the Win32 API so you could easily see why applications written on Windows/UNIX had different "issues".

These issues will be fixed in GCJ (GNU Compiler for Java). GCJ will provide a modern AWT implementation which should eventually support both GTK and QT.

Java is back baby! And this time it is Free and GNU powered!

Kevin

it's not an IBM project

[mj6798]

Mertz's affiliation is given as "Gnosis, Inc.", not IBM. The article is simply published in IBM's DeveloperWorks for Linux.

Not IBM...

[kraftknoedel]

You might be interested to know that this project has nothing to do with IBM. There is an article about it on IBM developerWorks, but that's it.

Also, it's not David Mertz's project, the project leader is Magnus Lie Hetland.

More info: http://anygui.sf.net/

Regards,
Kalle Svensson, PyGTK backend developer.

Re:In short, IBM says "Screw you guys, we'll do it

[nowt]

Someone then please explain why pygtk is unsuitable...?

seems very naive

[jilles]

SUN has been working for years to create a cross platform application framework. It is called swing. Swing is very complex and heavy on resources but it does the job. It supports printing, drag & drop, integration with the native clipboard, key bindings, skinning, all sorts of graphical stuff and lots of other stuff.

While you might disagree that Swing is a good solution, the fact remains that Sun realized that all of the above is needed if you want to create competitive GUI apps.

The solution suggested for python seems to make the same design mistakes sun made early on (AWT) and seems to be based on the same naive view on what comprises a good GUI. In addition it seems to ignore a whole lot of other perfectly good solutions (qt, gtk, XUL, Kylix, Swing, ...). Swing integration is easy if you use jython. I think there are also python bindings for Mozilla so you should be able to create XUL applications in python. Presumably integration with GTK or QT is also easy.

Wrapping is no good solution for anything but the most trivial applications. As soon as you make things more complex, you will have more and more trouble keeping things crossplatform since each platform works slightly different, has its own bugs to work around and may or may not support what you need.

Re:seems very naive

[Havoc Pennington]

Precisely. There is a reason GTK doesn't work like anygui, and a reason Qt/Swing/Mozilla/etc. also don't work like anygui, and a reason the AWT approach was dumped.

You can do cross-toolkit abstraction if you do it like AbiWord, where they often add features and hooks to punch through to platform-native if required. But that doesn't work in a generic XP toolkit.

Wrapper toolkits are very limited in power, there's just no way around it.

Python needs to bite the bullet, suck it up, pick one of the existing actively-maintained modern toolkits despite the possible flamewar, and then simply address its limitations (e.g. porting to platforms as required). Until then it won't have a standard GUI. Sometimes there is no silver bullet. ;-)

Re:seems very naive

[jilles]

I mostly agree with you actually. I just don't agree that the solution should aim for a minimal set of features that is common to all platforms since I strongly suspect that just like with AWT it will be an ugly mess. AWT provided just the basic features. You could instantiate a button, put it in a window and so on. However, even this simple functionality was too different from platform to platform which resulted in applications that had to be tested on each intended target platform to deal with all the platform specific quirks.

I agree however that there is a need for a crossplatform GUI kit. I only think that it should be a full featured one rather than some arbitrary subset. More importantly, I think it should be object oriented and language independent. Otherwise we'll see duplicated efforts for perl, ruby, whatever. Most of the existing GUI kits are language dependent or at least assume a great deal about the language used to work with them. This limits their usefulness. A good example is the GTK - QT debate. C programmers will likely favour GTK whereas C++ programmers will likely prefer QT. Swing is great when you use Java, but using it from another language is usually hard (unless it has an implementation ontop of the JVM).

Re:seems very naive

[SEE]

Which one of the "other perfectly good solutions" you mention (qt, gtk, XUL, Kylix, Swing) . . . is available on all the platforms that Python runs on?

First, I admit that XUL isn't exactly ideal for the kind of work he wants to do.

But, as far as platform availability, XUL already works under seven different GUIs (Win32, BeOS, MacOS, WPS [OS/2], X, Photon, and NanoGUI) and at least nineteen operating systems (Windows 9x/Me, Windows NT/2000/XP, MacOS, MacOS X, Linux, AIX, BeOS, Irix, OpenVMS, OS/2, HPUX, BSD/OS, Solaris, Tru64 Unix, FreeBSD, NetBSD, DG/UX, and QNX).

Okay, admittedly the DG/UX binaries are rather old, and the Photon/QNX ones might be (I can't find any data on whether recent milestones are available for it). But everything else on my list has a Mozilla 0.9.4 or 0.9.5 version.

Re:What about MacOS X?

[kraftknoedel]

AFAIK, there is currently no explicit support for MacOS X.

If MacOS X has Jython (swing), PyGTK, Tkinter or wxPython it should work out of the box anyway. If not, we would of course welcome a developer of a MacOS X backend!

Regards,
Kalle Svensson, PyGTK backend developer.

This is not a new GUI toolkit

[richw]

Most of the posts so far seem to have missed the point.

This is not a new GUI toolkit. It is a wrapper API for a large number of underlying graphic toolkits. You write code for AnyGUI and don't have to worry what GUI toolkit is used. "On Windows, the Win32 API might be used (or wxWindows); on MacOS, native calls; on BeOS, Bethon; on Linux, TKinter or GTK"

Also, as far as I know this is not an IBM project. The article is just published on an IBM site.

If this works as well as the AnyDBM module which allows basic database access from Python without having to worry about what actual database you are using it will be great.

Check out http://anygui.sourceforge.net/

Re:Mmm

[TeknoHog]

Now that's objective. I'm sure Guido agrees with me that Python is better, even not counting the OO features.

Gotta admit that Python is probably the only computing environment I've encountered, which is both easy to learn and powerful in the long run.

The downside is, of course, Python's more restricted syntax. I'd say Python and Perl codes compare like technical manuals and poetry. But when programming I'll rather take the tech (TeX :) route.

Or...

[Greyfox]

Wouldn't it be cool to apply some of the cool stuff we found in Design Patterns?

Sometimes we do write stuff just to learn. If what we've written also turns out to actually be useful so much the better.

wxWindows

[Sludge]

I am rapidly becoming a wxWindows fan. I've spent the last week or so learning this toolkit and implementing something like Gamespy or The All Seeing Eye.

I admit this is the first GUI toolkit that I've used (for the desktop), but it seems to be very clear to use. I've got most of the standard functionality down now - events, windows/frames, window sizing, encapsulated string handling, etc, and I've only had to consult the mailing list for a single issue.

I'm using it with C++, but there are some rather popular bindings for Python called wxPython, as well as Perl and an assortment of other languages.

And the thing that gives me wood is that it looks native in each environment. GTK+ with themes under Linux, and Win32 GUI widgets under windows. And yes, it manages to do this without taking the lowest common denominator route: Sometime features like traybar iconifing under Win32 get plainly ignored under other OSes.

Learned a new API this year? (If you are a coder...) If you have not, you're due.

Re:wxWindows

[Sludge]

It would seem to me anyone willing to undertake this entire project from scratch would be more than a small weight in the amount of contribution they could lend to the wxWindows effort.

Perhaps an interesting project would be a wxWindows target for an MFC reimplementation.

Defective O'reilly literature

[Ukab the Great]

Perl isn't an OOP language? Guess I need to tear out chapters 12-13 of my Camel Book.

Re:Mmm

[elflord]

that's because no perl code ever uses objects that they were implemented in such a bad way, but since no one uses them it doesn't matter,

This is demonstrably false. The majority of the perl toolkits that I've used do make use of perl objects. Sure, in your 100 line web program or sysadmin script, it might not matter, but when you want to write scalable modular software, it does.

On the other hand, most object oriented designs fail, take Gnome as the best example, circular library dependencies anyone?

GNOME is not a good example of "object oriented design", because very few OO projects use C as the implementation language. As for circular dependencies, that is simply indicative of poor design.

Not impressed

[elflord]

While the authors go out of their way to trash Java, I don't see how this is an improvement, in fact it looks worse. The problems I see are as follows:

1. Write once, debug anywhere -- this is a criticism the author makes of java, but it does not seem clear that "anygui" solves this problem. In fact, I would conjecture that it makes things even worse, because of the fact that anygui programs are supposed to be able to run on an even more diverse collection of platforms (eg including curses) To rigorously test an anygui application, you would certainly need to test curses and windowed versions, for example.
2. Ugly apps -- we're all familiar with the ugly-AWT app syndrome. The problem is that when you want to write an abstraction layer for several toolkits, you're stuck with the logical intersection of the feature set. The article explicitly mentions that "anygui" shoots at the lowest common denominator. This may have a useful niche for (eg:) installers, but for general purpose applications, it is not acceptable.
3. Object oriented ??? -- No, it seems rooted in the callback/event-loop paradigm, and that means it's going to be difficult to write nice applications (the signal/slot mechanism used in GTK/Qt is much cleaner IMO)

Anyway, I find it hard to get excited about this toolkit, because it looks to me like a solution waiting for a problem.

anygui is precisely the AWT

[SimonK]

What the article describes - a common interface to the lowest common denominator of a wide range of GUI toolkits - is exactly what the Java AWT did. Unfortunately the intersection of all common toolkits is quite small: many don't support graphics on buttons, or sliders. There are also significant differences in the behaviour of the widgets between platforms that create problems. It looks to me as if you haven't examined the AWT and the reasons for its failure in enough detail, so you're going to make the same naive mistake again.

On top of that, the callback/event-look API described surely went out with the ark.

alternative approach

[mj6798]

Python needs to bite the bullet, suck it up, pick one of the existing actively-maintained modern toolkits despite the possible flamewar, and then simply address its limitations (e.g. porting to platforms as required). Until then it won't have a standard GUI. Sometimes there is no silver bullet. ;-)

Alternatively, Python should mature to the point that people can write a toolkit in Python itself, relying only on drawing primitives from the platform (the same could be said about Perl).

Re:alternative approach

[Jason Earl]

Alternatively, Python should mature to the point that people can write a toolkit in Python itself, relying only on drawing primitives from the platform (the same could be said about Perl).

I don't think that this is a particularly good idea. Python is a scripting language, any GUI that relies too much on Python code is bound to be sluggish. That's the real beautty of wxPython (IMHO). It is a very nice wrapper around wxWindows, with a definite Python "feel." The fact that wxWindows is compiled means that WxPython GUIs are amazingly responsive. I ported some test apps from Java/Swing and was amazed at how much faster they ran and how much easier they were to write. WxWindows also uses the native toolkit, so your application appears to fit in with the rest of your environment.

Of course, I am more than a little biased, I personally think that a mixture of Python + C (or in this case C++) is about the perfect development blend. Prototyping is fast and easy, and Python is so easy to extend in C that making the application fast enough is very straightforward.

Anygui sounds like a nice idea, but any abstraction layer generic enough to include ncurses isn't likely to be capable of creating very complex GUIs.

Of course, if they prove me wrong, well I will be pleasantly surprised. I have wrong once or twice before :).

Python is great...

[Junta]

I especially think PyGTK is an example of somewhat relatively well-done work. In my experience with Perl and Python, Python tends to lend itself better than Perl for maintenance. However, the way in which data members of a class can be declared *anywhere* could create problems on larger projects. Also, having to have self as an argument to your class functions is a bit strange, and having to reference all class methods and members explicitly through self is a bit strange too, strange way of distinguishing between local and class methods and variables. And the way private vs. public is a bit strange. Other than this, I really like Python, a really impressive interpreted language, with a really excellent way to interface with C code, more impressive to me than any other non-C language, espeically makes JNI of Java look like complete crap.