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."

WxPython

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

What about MacOS X?

Well, what about MacOS X?

Anybody know anything about future Python support for the X as well as this anygui?

I like this idea.

I have been working with Python sience this summer Ranging from Web Apps to console apps. I find it real nice because I dont usually have to annoy the administer to add more modules on to the system (like in perl), Pluse my code comes out really clean and most of the time the programs are cross platform so it makes distribution a lot simpler. And the main reason I usually avoided using graphics in Python is because the GUI interface needed a tcl/tk program and that becomes more of a hasel for distribution. If they can come up for more of a common graphical interface that can be imbedded into the Python source and works platform independent I am all for it.

random Java flaming again

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.

awt ?

"...The emphasis of anygui is to provide a usable set of interface elements that will work with every backend; particular backends might themselves be capable of more advanced interfaces, but anygui sticks to what is common to them all. ..."

it looks like awt.

awt was replaced by swing because by sticking with
lowest common denominator, you end up with just
very simple (and not very useful) widgets.

Reminds me of my comp sci professor

Who always used to say there is no problem in Computer Science that can't be solved by adding a layer of indirection :-).

Someone should try this with perl, it could use a good abstraction layer like this.

Not IBM...

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.

seems very naive

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.

This is not a new GUI toolkit

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/

Won't work

If it did work, somebody would have done it by now.
Java tried it, failed.
Netscape tried, failed.

Woot!

More justification to love python. I use it for everything. Unfortunatly the apache mod_python interface sucks badly if you want to use it the 'proper' way. But this anygui sounds great. I wrote an app in tkinter and made it into a stand alone windows program, but it had to include so much crap to make sure it ran, the simple program turned into a 3meg bloat. I wrote another program in pygame (SDL interface,) and it came out a lil smaller, ~1.5megs. But I think the main goal with anygui would be ubiquitousness. The GUI you need is already there, so if I were to make stand-alone windows programs, it wouldn't be bloated including the GUI libraries. This is great!

Pythons big advantage over Java....

Though Java rox as a language and was the first to implement the VM principle and has a huge set of APIs (which make for it's biggest advantage but often are written very haphazardly), it has one big downside in comparsion to Python.

Python is GPLd. Java is not.

If the other-way-around aproach IBM is taking now is crappy, there be no one stopped from enhancing it or writing a better one. Everyone can go by and rewrite any part of the Standard library if he thinks it's to slow. If IBM wants to bug SUN a little in the "nifty new language concept" dept., this is not the stupidest thing to do.

I'm for it

Having dabbled in Python programming, I see this as a Very Good Thing (TM). I read the article, and as others have pointed out, this is not a new GUI toolkit, but a wrapper for all of them. So now I can write Python programs that use both PyQT (Linux) and Tk (Windows) without having to learn two different toolkits.

Now if only PyKDE2 would come out soon, so that I can start making a couple of kicker applets for KDE2. Of course, by the time PyKDE2 is out, KDE3 will have come out, and the whole cycle will start over again!

Listing of available Python GUIs

For a fairly comprehensive list of Python GUIs check out Cameron Laird's page [neosoft.com]. Many interesting wrappers out there (PyQT, PyKDE, PyGTK, wxPython, VTK, FOX, etc).

I love choice, but part of me wishes that more effort would go into getting wxPython/wxWindows polished (and more fully cross-platform) to knock Tkinter from its status as defacto Python GUI.

Not an IBM project

anygui [sourceforge.net] is not an IBM project -- it was just reported on in IBM developer works. If they write an article on java, does it mean they invented java? Sheesh.

From the website:


The purpose of the anygui project is to create an easy-to-use, simple, and generic module for making graphical user interfaces in Python. It's main feature is that it will work transparently with many different GUI packages on most platforms.

You can use it to write a generic GUI app and it will scan the gui toolkits on your box and choose the best one to use for your app.

A successful project with analogous goals is anydbm [python.org]
You can make generic operations on databases, and it will work on mysql and postgresql. It's already a part of the standard python distribution.

wxWindows

I am rapidly becoming a wxWindows [wxwindows.org] 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.

Don't forget about QT!

http://stage.linuxports.com/projects/pyqt/book1.ht m

The only book on Python and QT programming

Not impressed

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.

Clarifications from the Author

I am David Mertz, the author of the referenced (but somewhat mis-described) article on IBM developerWorks about anygui. Some other folks have posted several clarifications, but let me try putting them together in one place.

1. I am not the lead developer of Anygui. That honor belongs to Magnus Lie Hetland, who has been doing a wonderful job. As indicated in the article, or on the project page, I -did- volunteer to lead one tiny aspect (but have not yet done any work, for which I apologize).

2. Anygui is not sponsored by IBM. I just write columns for IBM, and found the project interesting enough to devote an installment to.

3. Anygui does not "repeat the mistakes of AWT", nor does it aim to replace another toolkit like GTK or Fox. Anygui is a *wrapper* around lower-end toolkits. The idea is that you can distribute *identical* source code to different users, on different platforms, and have it run with *some* available backend.

4. Anygui will never be as feature-rich as many of its backend toolkits. It is not trying to be. The aim of Anygui is to provide a minimal, but -universal-, GUI API. If you want the full sophistication of, e.g. Swing, don't use Anygui. If you want users of Jython, MacOS native, Win32, and PyGTK (and others) to all be able to receive and run (without modification) your common Python code, Anygui is a brilliant project.

Python is great...

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.

It's like the XML parser model

The idea of a API which provides a way to hook into whatever provider exists on a platform reminds me of the SAX [megginson.com] XML event-driven interface. Right now it does not seem to provide much that an effort to port Tkinter to the "minor" platforms might give you, but maybe in the future it might be able to let a GUI app query the underlying provider whether certain capabilities (e.g. bitmaps on buttons) are supported and make intelligent choices based on that information.

it's not an IBM project

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

Re:Mmm

"Perl is worse than Python because people wanted it worse". Larry Wall
(Creator of Perl), 14 Oct 1998

source:
http://www.mindview.net/Books/Python/ThinkingInP yt hon.html

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

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

Re:Mmm

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.

Defective O'reilly literature

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

Re:Mmm

This is what people who have never truly grasped OOP always say. It seams to be 'I don't know how to use it so it must be bad!'. This is, of course, utterly false. OOP projects take a bit longer to create but maintainability and extensablity more then make up for it.

As for the speed issue, that argument was made when programmers moved from C to Assembler. I am sure there are still a few assembler programmers out there saying

'What's this shit with Procedural Programming? PP is a sinking ship, it's been already demonstrated a hundred times that it shows no advantages (except for morons who don't know what they're doing) and is always 5-500 times slower, take C for example.'

So your argument is worthless. I would say pick up and OOP book and spend the next six months or so tring to come up to speed. When the 'Aha' moment strikes you may take back your post.