Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Generic GUI Wrapper For Python 114

Posted by timothy from the operating-systems-shouldn't-matter dept.
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."
This discussion has been archived. No new comments can be posted.

Generic GUI Wrapper For Python More

Generic GUI Wrapper For Python

Comments Filter:

  • WxPython (Score:2, Informative)

    by redcliffe ( 466773 )
    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
    • wxPython is great for programming real applications. It now runs on win32, gtk, motif and macos. But on a BeOS box or on a palm or (insert your favourite device here) it is not available. AnyGUI would run on ALL platforms because it uses the already installed GUI.
      Python itself is available for many many platforms: linux, win32, solaris, os/2, amiga, beos, qnx, vms, psion, acorn vxworks, ibm as/400, playstation, palm, winCE
      and you could write a program once and it would use the native GUI on the respective machine.
      cheers
      • the interesting part about this anygui, and the part that makes me the most skeptical...is that one of their intended targets, along with wxWindows, GTK, mac native, etc...is ncurses. Somehow I just don't believe that they'll be able to write a toolkit so generic so writing a UI that looks fine in GTK looks fine in a console.
  • Well, what about MacOS X?

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

    • Many people have stated their desire for a standard Python GUI. Tkinter comes moderately close -- it has stable versions for Windows and UNIX/X Window Sytem, and a passable MacOS version.

      When they say "passable MacOS version", do they mean Classic or MOSX?

      • When they say "passable MacOS version", do they mean Classic or MOSX?

        They mean classic Mac OS. I got TiK [sourceforge.net] to run on it once; here's a screen shot [brad-x.com]. There seemed to be no support for the menubar, or right-click contextual menus, or of course sound (since I believe TiK cats .au files to /dev/dsp). I'll see if the newer versions run better.
      • I don't know about that....but I once ported a script from Perl Tk to Python tkinter (both on Windows), and it leaked memory hardcore. It was just a little window with 2 scrollboxes and a few buttons, I left it running once overnight and the next day it was using something like 80 megs of ram. Not exactly what I'd call stable anyway...
    • 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.
    • Well, what about MacOS X?
      Anybody know anything about future Python support for the X as well as this anygui?

      Tk in 8.4 has a native Aqua port [apple.com] (Oct 16 news) in beta, from the guys at Apple. All languages binding to Tk can take advantage of OS X now.

      In any case, this has been said, but the idea of anygui being the lowest common denominator of toolkits seems like a bad idea being repeated. Tk has been inflicted by this sometimes, but more and more pressure is on Tk development to add more single-platform support bits in the core.

  • 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 (Score:4, Insightful)

    by mj6798 ( 514047 ) on Saturday October 27, 2001 @07:53AM (#2487017)
    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.

    • Did you go to their website?
      As far as I see they just want to create an abstraction layer for the different gui toolkits in python. Even for text and html.
      I think this is very neat and definatly not NIH.
    • I think that proves the point of not programming the 'write once run everywhere' style. It's a promise just as RAD is a promise and just as all the CASE tools promise you heaven without sweat.

      You could argue this, and propose to use a 'common widget set' with 'common behaviour' across all platforms, but this will alienate your software's GUI from the rest of the system. As a Windows user, I resent anything that behave's like a Mac or like a Sun, how subtle the differences may be.

      IMHO, true cross-platform development means separating your GUI from your internals, and keeping the functionality platform independent. Ansi C++ for this (including STL) is maybe a good choice, but I'm not a C++ developer.

      Just my 0.02 Euro

      Dave

    • 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

  • awt ? (Score:1, Interesting)

    by Anonymous Coward
    "...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.

  • 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... (Score:5, Informative)

    by kraftknoedel ( 10177 ) on Saturday October 27, 2001 @08:28AM (#2487047) Homepage
    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 (Score:3)

    by jilles ( 20976 ) on Saturday October 27, 2001 @08:35AM (#2487053) Homepage
    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.

    • did you actually read the article?
      they aren't ignoring qt,gtk,swing and others. they are using them!!
      they are making on unified way to access them from python,so that the user can choose which one he want to use.

    • 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. ;-)

      • It's views like yours that hinder learning and research. It's those same views that stop people from making vast breakthroughs that may alter the landscape of their specific field.

        "It can't be done!"
        "It's been tried, and that failed. If they couldn't do it, you can't".
        "That impossible to do."

        Things like what you just said, were said for a multitude of things, (i.e. Nukes, lasers, space flight, UNIX, X, Linux). But guess what, they all happened.

        Will this project change the landscape? No. Will this project alter history? No. Does the possibility exist that this project will force developers to look at their code differently? Yes. That's all that needs to exist to make this project worth while to the developers who choose to develop for it.

        I don't care if you're a "well-known hacker". I don't care that you're the "Chairman for the Gnome Foundation", and, right now, I couldn't care less if AnyGUI went away. For you to completely blow off the whole project just shows me how short-sighted you are.

        This is open-source. You don't like the project, don't use it. Let them do their thing, you go do your thing, and everyone is happy. Maybe within a year or two they, or some other project, will show you up and prove that it can be done.

        And yes, AWT was dumped.. by a corporation who failed to see enough profits to come from their investment. This is not a corporation, they are not driven by their bottom line. You, of all people, should recognize that.

        --sea
        • It's those same views that stop people from making vast breakthroughs that may alter the landscape of their specific field.

          Nonsense. No-ones trashing "anygui" for being new and challenging conventional wisdom. It's being criticised because it's a rehash of old designs. If there were some evidence that the authors better understood the pitfalls of similar projects (AWT being a good example), and had some plan to address these issues, perhaps the posters here would be less cynical.

          The article trashes java, while failing to point out how "anygui" will avoid the same pitfalls.

          And yes, AWT was dumped.. by a corporation who failed to see enough profits to come from their investment.

          And a corporation who realised that a complete redesign would be a more effective use of limited resources than trying to fix AWT. Or are you trying to argue that Swing was a triumph of marketting over good design ? I think you'd find anyone who'd used both toolkits would find that laughable.

      • 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).

        • 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 :).

    • Comment removed based on user account deletion
    • Anyone who says "Why aren't they just using toolkit X" or "They're never going to be able to make animated skinnable toolbars with dancing frogs" is missing the point entirely. Comparing this project to AWT or Swing is missing the point entirely. This team is not reaching for the same goal as the Java team was, i.e. to be a world-class competetive GUI. There are two keywords for this project:

      Minimal: The goal is to have a *minimal* set of widgets that allow the most common types of input and output. The idea is to make a toolkit that anyone can use to create a *simple* gui on any platform that Python runs on.

      Universal: Which one of the "other perfectly good solutions" you mention (qt, gtk, XUL, Kylix, Swing) does *everybody* have? Which of them is available on all the platforms that Python runs on? None of them, of course. The whole point is that no single toolkit is going to satisfy this requirement, so more than one toolkit needs to be supported.

      What most of the posts I've seen so far lack is an understanding of the current situation in Python. The language is great for programming almost any kind of non-realtime project in a cross-platform way, but it lacks a way to write cross-platform guis without asking the user to download a 5 to 10 MB window toolkit on one or more of Python's platforms. This is simply unacceptible when you're distributing a 150 kB Python program! Hell, it's hard enough to get people to download the python interpreter!

      There is a real need for this project in the Python community, and I wish them great success.

      -DA
      • 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).

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

  • This is not a new GUI toolkit (Score:4, Informative)

    by richw ( 20467 ) on Saturday October 27, 2001 @08:42AM (#2487057)
    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/
    • ... on Linux, TKinter ...

      Actually, tkinter works cross-platform. I use Python a lot, and I have used tkinter on Macintosh (an old 68040, not a modern Mac) as well as UNIX. I am told that tkinter works in Windows, but I have never used it there myself. As far as I know, you don't need to change your code either, or at least I have never had to. If you are using Python to do something GUI-style, tkinter is an excellent choice, especially because of the easy cross-platform support.

  • If it did work, somebody would have done it by now.
    Java tried it, failed.
    Netscape tried, failed.
    • This cross platform stuff is the crack dream of GUI programming going back 20 years. You get least-common denominator support for the underlying GUI, and another layer of code to harbor bugs.

      It's a great example of how an idea that seems good when discussing it in a CS class, falls apart where the rubber meets the road.

      - adam

      • It's a great example of how an idea that seems good when discussing it in a CS class, falls apart where the rubber meets the road.

        No, it's an example of a very real world thing called an engineering trade-off. They are trading-off feature richness for universality.

        If someone needs a universal GUI library, and can live with the lack of features, then this could be a good solution. They are attempting to provide one solution to a particular problem. For free. That is commendable.

    • hmm, that sounds familiar... where have I heard that statement before? Oh yeah, from Microsoft(about Linux), for C++ developers(about Java), and from just about every other nay-sayer who thinks that a tool can't be made, or won't work. Television, radio, electricity, and the telephone come to mind.


      Let them try. You don't like the project, don't use it. Much like if you don't like KDE, don't use it.


      I'm tired of people like you. If a developer chooses to develop for a project, then that developer thinks it can be done. And the opinions from the likes of you shouldn't stop them. God knows where the world would be if everyone listens to opinions like that.



      --sea

      • I did not say don't try.
        Just said it won't work.

        PS - WTF is this:

        Slashdot requires you to wait 20 seconds between hitting 'reply' and submitting a comment.

        It's been 15 seconds since you hit 'reply'!

  • Woot! (Score:1)

    by 8bit ( 127134 )
    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!
  • 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.
  • 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!
  • 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.

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

    • A successful project with analogous goals is anydbm. You can make generic operations on databases, and it will work on mysql and postgresql.

      anydbm is a generic interface to variants of the DBM database, not relational databases like MySQL and Postgres. For relational databases the generic interface is DB-API.

      Hamish Lawson

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

    • Thanks for pointing this project out. I was in the midst of doing something very similar to this (exactly this actually). Now, I'll just throw my small weight behind this since they're a ways ahead of me.

      Now.. I have to go read their source.. go about your business..

      --sea
      • 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.

        • Er, why? Most Windows coders are using ATL / WTL. Even MS don't actually _use_ MFC for anything except maybe Wordpad...
  • http://stage.linuxports.com/projects/pyqt/book1.ht m

    The only book on Python and QT programming
  • 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.

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

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

Slashdot Top Deals

Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson

Close