As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Simple question:
What Python GUI API's are out there and what are the advantages of any given API?
I'm not looking for a religious war here, I'm just wanting to get a good handle on all that is out there in terms of Python GUI APIs.
Here's a good list.
I've used Tkinter and wxPython. Tkinter is quite basic, and doesn't use native widgets. This means that Tkinter applications will look the same on any platform – this might sound appealing, but in practice, it means they look ugly on any platform :-/ Nevertheless, it's pretty easy to use. I found Thinking in Tkinter very helpful when I was learning, because I'd never done any GUI programming before. If things like frames and layout algorithms and buttons and bindings are familiar to you, though, you can skip that step.
You can augment Tkinter with Tix (but be warned, Tix doesn't play well with py2exe). Also check out Python Megawidgets, which builds some more advanced controls using the Tkinter basics.
Finally, Tkinter plays nice with the shell: you can start the interpreter, do things like 'import tkinter' 'tk = tkinter.Tk()' etc. and build your GUI interactively (and it will be responsive). (I think this doesn't work if you use IDLE, though)
wxPython is much better looking, and ships with a much greater range of controls. It's cross-platform (though it seems a bit finicky on my Mac) and uses native controls on each platform. It's a bit confusing, though. It also ships with a demo application that shows off most of its features, and provides a test-bed for you to experiment. Some specific thoughts on wxPython:
There are three (?) different ways to lay widgets out. Ignore two of them; just use Sizers. And even then, you can do just about any layout using only BoxSizer and GridBagSizer.
All wx widgets have IDs. You don't need to care what the IDs are, but in the old days (I think) you did need to know, so some old code will be littered with explicit ID assignments. And most demo code will have -1 everywhere as the ID parameter (despite the fact that the methods all have ID as a keyword parameter that defaults to -1 anyway).
Make sure you get the standard wxWidgets docs as well as the wxPython Demo – you need them both.
If you want to use wxPython with py2exe and you want it to look good on Windows XP, you need a bit of trickery in your setup.py. See here
PyQt is excellent if you have experience or interest in Qt.
http://www.riverbankcomputing.co.uk/software/pyqt/intro
Most python GUI APIs will be wrappers around the most common c/c++ GUI APIs. You've got a python wrapper for gtk, a python wrapper for qt, a python wrapper for .NET, etc etc.
So really it depends on what your needs are. If you are looking for the easiest way to draw native-looking widgets on Linux, Mac, and Windows, then go with wxPython (python wrapper for WX Widgets). If cross-platform isn't one of your needs though, other libraries might be more useful.
Instead of posting a list of your options I will give my humble opinion:
I am in love with wxPython.
I have used Qt in C++ and Tk way back in the Tcl days but what really makes me like wxPython is the demo that you get with it. In the demo you can browse through all the different widgets frames etc that are part of the framework see the source code and actually see how it looks while it is running.
I had some problems getting the Linux version build and installed but now that I have it available I use it all the time. I have used wxPython for small data analysis applications and I have written several internal tools related to comparing test results, merging source code etc.
I found this link a long time a go: http://www.awaretek.com/toolkits.html. It suggests a tookit based on your criteria. For me it suggests wxPython all the time. Anyway it gives you a bunch of scores on the various toolkits. What is right for me may not be right for you. But it gives you how all the tookits scored according to your criteria, so if you don't like the top toolkit for some reason you can see which ones are closest to your criteria.
QT/GTK/WxWidgets (formerly wxWindows) seem to be among the most mature cross platform GUI toolkits. The only issue is that none is installed with the default installation of Python, so you may have to compile the libraries. If you want something with no installation required that just runs, then go with TKInter because as has been mentioned it is installed by default with Python.
Anyway my criteria were 9 on Ease of Use, 10 on maturity of documentation/widgets, 10 on installed base, 5 on gui code generators, 10 on native look and feel for both windows/linux and 1 and 5 for the last two, I'm not big into Mac OSX (even with a 10 here it suggests wxpython).
PythonCard is really easy to use. That's what I would recommend.
Here's their writeup:
PythonCard is a GUI construction kit
for building cross-platform desktop
applications on Windows, Mac OS X, and
Linux, using the Python language.
The PythonCard motto is "Simple things
should be simple and complex things
should be possible."
PythonCard is for you if you want to
develop graphical applications quickly
and easily with a minimum of effort
and coding. Apple's HyperCard is one
of our inspirations; simple, yet
powerful.
PythonCard uses wxPython. If you are
already familiar with wxPython, just
think of PythonCard as a simpler way
of doing wxPython programs with a
whole lot of samples and tools already
in place for you to copy and subclass
and tools to help you build
cross-platform applications.
EasyGUI is different from other GUIs in that EasyGUI is NOT event-driven. It allows you to program in a traditional linear fashion, and to put up dialogs for simple input and output when you need to. If you have not yet learned the event-driven paradigm for GUI programming, EasyGUI will allow you to be productive with very basic tasks immediately. Later, if you wish to make the transition to an event-driven GUI paradigm, you can do so with a more powerful GUI package such as anygui, PythonCard, Tkinter, wxPython, etc.
EasyGui Website
WX has issues on the Mac.
I had a look here, as I want to get an event driven GUI API to do some stuff in Python. I have wx installed on my mac as part of MatPlotLib, but it does not work properly. It wont take in put from the keyboard. I have installed this three times on three different Mac operating systems, and though it worked the first time, the other two times I had this issue.
This version I am using with Enthought's distribution, so no installation was necessary. When I have installed it separately, there were so many dependent installations, that it was a trial to install.
From what I have read here, I will give Tkinter a go, as this needs to be simple and cross platform, but I thought I would just share the above with you. I like the Mac OS for a number of different reasons, but python tools install far easier on Windows (and probably other Linux). I just thought I would give a Mac perspective here.
I like wxPython or Tk.
Tk comes with the standard Python distribution so you don't need install anything else.
wxPython (wxWigets) seems much more powerful and looks a lot nicer. It also works well cross-platform (though not perfectly because it uses different underlying graphic API's on diff system types)
I prefer PyGTK, because I am a GNOME guy. Using PyGTK feels very pythonic to me. The code organization feels consistent, the documentation is clean and thorough, and it's a very easy toolkit to get used to (except for maybe Treeviews).
An easy to use GUI creator for Python doesn't exist. That's amazing really considering small scripting languages like AutoIt and AutoHotkey have great and very simple to use GUI makers. Come on, Python followers, can't you do better?
I've been working with wxPython for a few years now and I like it quite a bit. The best thing about wxPython is that the UI feels native on the different platforms it runs on (excellent on Windows and Linux though not as good on OS/X).
The API lacks some consistency, but you quickly get used to it.
You can check out Testuff (shameless plug, as it's my own product) to get a feeling of what can be done with wxPython (although I must say, with quite a bit of effort).
wxPython, and I'm assuming PyGTK also, can use wxGlade to help you design most UIs you will create. That is a big plus. You don't have to learn how to hand-code the GUI until you're ready. I made several GUI programs straight from wxGlade before I was comfortable enough in how wxPython worked to take a shot at hand-coding.
PyQt has a similar graphic layout device but I've never had good luck getting PyQt to compile correctly. There was also a lack of tutorials and documentation that showed how to create the final Python code; many of the documents I found referred to the C++ version of Qt.
Tkinter is good for quick and dirty programs but, realistically, if you use wxGlade it may be faster to make the program with wxPython. At a minimum, you can use wxGlade to show a visual representation of the program to a client rather than take the time to hand-code the "dummy" program.
There are python-specific gui-api such as kivy (successor or pymt), pygui (based on pyrex), pyui and nufox, which do not compare with the more robust toolkits like wxpython, pyqt, pygtk and tkinter.
They are just extra optional tools.
The only thing unique about them is these are python-specific api, just like there are prima (perl-specific api) and shoes (ruby-specific api). It helps us to understand that when tk is tcl-based port of api (and others are c and c++ based), then these api are specifically done for the respective three scripting languages.
Out of these, kivy is the most robust, whereas pygui's coding is mentioned to be very python-like, pyui is least robust but worth trying and all of these should be portable wherever python or python-based application goes.
Then there is jpype which is a toolkit usable with jython and pydev, and which is actually java's japi customized under python/jython-interface.
Related
I'm planning to take a non-GUI Linux distro (no Gnome, KDE, etc) and build my own front-end GUI for it. While I have a few years of Python programming experience, I have never attempted to do something quite like this.
To be more specific about my project, I'm building a CarPC and I have everything pretty much worked out so far, except the front-end. Most pre-existing front-ends for CarPCs run on Windows and the ones that run on Linux are hard to find (they either quit development or only run on specific hardware). My front-end will always be full-screen and I do not want to run a desktop environment unless I absolutely have to; it would just slow down the boot time and provide unnecessary features.
My question is basically where I should start. What Python graphics libraries are out there that would allow me to build a front-end GUI without a desktop environment?
You'll probably want to look at other answers and questions on this topic such as this one
Another good link is this one on the Python websitewhich lists different GUI toolkits.
While I haven't used it, Kivy looks like a good place to start. It's apparently got touch screen capabilities which I assume you would use and it doesn't look constrained to a GUI desktop env.
Hopefully you can find a way to do this without a desktop env. If not perhaps consider using X11 as your layer and go from there.
You should probably consider DirectFB. You can even use a DE on it if you like (although not required).
WxPython is awesome. I use it with Python and plain WxWidgets in C++ too. I've had great luck with making native GUIs from it and internationalization is supported too. Good luck!
Edit: I missed the "without a desktop environment bit". I'm not sure my answer is relevant. You should edit the Title of the question. Just disregard.
I have a little programming experience and I did get to work with Swing (Java) and wxPython.
Some years ago, I ended up having to port an app I did to OS X and all the problems I've had with wxPython just multiplied. I've started looking at alternatives and I could not find anything better than wxPython. QT was the only one that came even close. GTK was hell on Windows (last time I checked).
I don't think my predicament is unique, some other people might have reached the same position over the years.
So, why isn't there a GUI toolkit to have the following characteristics:
Simple. Basic windows/dialogs (native open and save) + a basic set of widgets with SOLID Layout management. Additional (composite widgets) implemented as additional libraries.
Actively maintained on OS X, Linux and Windows
Actively maintained bindings to at least 3 high level languages.
Actively maintained documentation for best practices GUI devel with examples using the toolkit. MVC/MVP properly explained. GUI HIG (Apple style) simply explained, complete with semantics, paradigms, best practices, alignment, proper spacing and TONS of best of their kind examples from successful pieces of software.
A simple way of building a distributable executable for the 3 targeted platforms in each of the languages.
Implemented as close to the metal using readily available libs like Clutter, cairo, etc.
Are these requirements too much to ask? If yes, why?
Help me understand why isn't there such a tiny lib available?
Have you tried Qt? It is a cross platform C++ GUI toolkit for higher level language (PyQt). And it seemed very simple to me.
What you ask is a simple lib with enormous flexibility. Be able to build 3 * 3 executables, having good documentation and using other libraries all with a different background. And all of that on different OS platforms. It is quite a challenge it think QT would com the closest but it does not meet all your criteria.
SWT? You can use it from Java, Python (well, Jython), Ruby (well, JRuby), Groovy, LISP (well, Clojure), and anything else that runs on the JVM.
It's simple-ish, it uses native widgets under the hood, it's actively maintained, and because you're distributing either a JAR or a JAR and some interpretable code, there's a unified build process. I can comment on its documentation, nor its proximity to any sort of metal.
I recognize that this is probably not the answer you were looking for.
My guess is that windows developers couldn't be bothered as they have wpf etc and linux developers couldn't be bothered as they are used to it. So only people who are sick of win developement and moving to linux would embrace it. Maybe its time for you to start an open source project :) I was thinking something like wpf but based on opengl would be a good start.
The Tk toolkit meets most of your requirements, except maybe for number four. It's very cross-platform, uses native widgets when possible, is easy to use, etc. The requirement for distribution is hard to meet because that depends on the language, but when used with tcl, you can use tclkits and starkits which are an absolutely fantastic way to distribute code (essentially, your single-file executable has an embedded virtual file system that can contain all your assets -- code, images, etc).
For more on the cross language, cross-platform features of tk see http://www.tkdocs.com
WXWidgets seems a good fit as well.
I'm under the impressions that Python runs in the Triforce smoothly. A program that runs in Windows will run in Linux. Is this sentiment correct?
Having said that, if I create my application in QT For Windows, will it run flawlessly in Linux/Mac as well?
Thanks.
Yes. No. Maybe. See also: Java and "write once, run anywhere".
Filesystem layout, external utilities, anything you might do with things like dock icons, character encoding behaviors, these and more are areas you might run into some trouble.
Using Qt and Python, and strenuously avoiding anything that seems tied to Windows-specific libraries or behaviors whenever possible will make running the application on Mac and Linux much easier, but for any non-trivial application, the first time someone tries it, it will blow up in their face.
But through careful choice of frameworks and libraries, making the application work cross-platform will be much more like bug fixing than traditional "porting".
As other posters mentioned, the key issue is making sure you never touch a different non-Qt non-cross-platform API. Or really even a different non-Qt crossplatform API, if you use Qt you kind of need to commit to it, it's a comprehensive framework and for the most part sticking with Qt is easier than going to anything else. There's some nice advantages as the basic primitives in your program will work the same way all over the place. (i.e. a QString in your networking code will be the same as a QString in your interface code.) Portability-wise, if you stay within the API Qt provides you, it should work on multiple platforms.
There will be areas where you may need to call some Qt functions which provide specific cross-platform tweaks more important to some platforms than others (e.g. dock icons) and you won't immediately have a polished application on all three platforms. But in general, you should remain very close to an application that compiles and runs on all three. (Try to use qmake or a similar build system too, as the build process for Qt applications varies depending on the platform. Different flags, etc.)
There's some odd issues that come up when you mix Qt with other APIs like OpenGL, in particular the way windows locks GL contexts differs from the way OS X and Linux does, so if you intend to use OpenGL with multiple threads, try to periodically compile on the other platforms to make sure nothing is completely busted. This will also quickly point out areas where you might have inadvertently used a non-cross-platform system API.
I've used Qt with a team to build a multi-threaded 3-d multiplayer real-time networked game (read: non-trivial application that fully utilized many many areas of Qt) and we were nothing but blown away by the effectiveness of Qt's ability to support multiple platforms. (We developed on OS X while targeting Windows and I regularly made sure it still ran on Linux as well.) We encountered only a few platform specific bugs, almost all of which arose from the use of non-Qt APIs such as OpenGL. (Which should really tell you something, that OpenGL was more of a struggle to use cross platform than Qt was.)
At the end of the experience we were pleased at how little time we needed to spend dealing with platform-specific bugs. It was surprising how well we could make a GUI app for windows given almost none of the team actually used it as a primary development platform through the project.
But do test early and often. I don't think your approach of writing an entire application and then testing is a good idea. It's possible with Qt, but unlikely if you don't have experience writing portable code and/or are new to Qt.
Yes. The code that you write using Qt will work on Windows, Mac, Linux/X11, embedded Linux, Windows CE and Symbian without any change.
You can take a look here.
Generally - as long as you don't use code that is not covered by Qt classes - yes.
I have several time just recompiled applications I wrote in Linux(64bit) under Windows, and the other way arround. It works for me every time.
Depends on your needs, you might also find compiler problems, but I am sure you will know how to work around them. Other people mentioned some issues you should look for, just read the other posts in the question.
It might run well, but it will take some testing, and of course Qt only handles the GUI portability, not the myriad of other things that might cause portability problems.
Qt apps generally don't fit in very well on MacOS because they don't have Applescript support by default and don't necessarily have the right keybindings. But if you do the work to fix those issues, they work, but not nicely. On the Mac, it's far better to build a native UI. If this is an in-house app, Qt is probably OK, but if it's for sale, you won't make many sales and will create yourself some support hassles.
As the others said, everything which is done using Qt-Functionality will most likely run quite flawlessly, WHEN you dont use platform specific functionality of qt.
There isnt that much (most of it has to do with window-manager stuff) , but some things might not work on other systems.
But such things are surely mentiond in the documentation of Qt.
Still there are things which cant be done using Qt, so you will have to do that yourself using plain Python...
Yeah "Python" itself is platform-independent (well it should), but there are lots of other things involved ... well mainly the OS.
And how the OS reacts you will plainly have to findout yourself by testing the application on all target OS.
Recently i wrote an quite simple GUI-application, while it ran flawlessy on Windows, it didnt run on Linux, because on Linux Python interpreted files encoded in unicode differently than on Windows.
Additionally a small script which should return the hostname of the machine, which it did on Windows, only returned "localhost" on Linux, which was obviously not what i wanted.
Quick question.
I'm using Linux and I want to try making a GUI with Python. I've heard about something like Qt, GTK+ and PyGTK but I don't know what they are exactly and what the difference between them is.
Is there any difference on how they work with different DEs like GNOME, KDE, XFCE etc.? Is there any IDE that allows you to create GUI like Microsoft Visual Studio does (for C#, C, Visual Basic etc.)?
Or should I maybe use another language other than Python to make GUI applications?
Your first step should be http://wiki.python.org/moin/GuiProgramming
Some tool-kits integrate better in one environment over the other. For example PyQt, PyKDE (and the brand new PySide) will play nicer in a KDE environment, while the GTK versions (including the WX-widgets) will blend better into a GNOME/XFCE desktops.
You should look at the environment you want to target. You can go for basic portable GUI kit, or you can to a deeper integration with tour DE, like use of integrated password manager, and configuration file parsers, that are integrated in a specific DE like KDE or GNOME.
You should also consider the dependency that your selection dictates, and what is come by default with a basic DE. For example, PyKDE in the KDE 3.X branch had a non trivial set of dependencies, while at the 4.X branch the plasma binding made the Python GUI programming dependency less of an issue.
There are several IDE tools, in different levels of completeness and maturity. The best thing is to try one ore more, and see what best fit your needs.
I would avoid using another language to make a GUI for Python.
I've had every good luck with wxwidgets, which is the python binding for WX, a cross-platform development system. It's pretty easy to learn and quite powerful. The problem with wxwidgets is that it is not installed by default, so your users will need to install it on every platform that they wish to run your application. Find more information about it at http://wxwidgets.org/.
If you want people to be able to use your program without installing anything else, use Tkinter, the GUI system that comes with Python.
I would avoid the Python bindings for GTK or KDE unless you already know those systems. They also need to be downloaded, and they do not seem to have as much adoption as wxwidgets.
Each desktop environment uses a specific toolkit to build it's components. For example, KDE uses Qt and GNOME uses Gtk.
Your use of a toolkit will be dependent upon what type of desktop environment you're targeting at, and if you want to target a wide range of desktops then use a toolkit which will work on many desktop environments, like Wx widgets which will work on Linux, Mac OS and Windows. For building simple GUI applications, Tkinter will do.
Use the glade UI designer and pyGtk bindings... that was my first ever experience with python and there are lots of blog posts and tutorials to help you get started
Use PyGTK. As important as the toolkit is its underpinnings, with PyGTK you use GLib as well, with its filesystem abstractions (python module gio) that are very important for the Linux desktop, its high-level cross-desktop functions such as glib.get_user_data_dir() and its other application framework tools, and GObject and its property and signals model.
I am a Python/web programmer.
Now, I would like to transition to building applications for the Mac.
Please tell me--what do I have to learn to get started?
What books would you recommend?
Assuming that you included the "python" tag after considering that it will be interpreted as applying to the question and not the questioner, you must be interested in writing Python applications for the Mac, right? After all, you didn't include "web" as one of the tags too.
If that's true, I'm not sure what more you need to know already, other than perhaps picking a GUI framework, if you want to write GUI applications.
I use wxPython quite successfully for applications which run on OS X (and Windows). Very few Mac-specific issues have cropped up to cause trouble, primarily because both Python and wxPython are remarkably cross-platform. The few that have come up are by and large documented and have known workarounds, or the resolution is fairly simple to find.
I've needed no books on the subject, and really know very little about Macs. It really hasn't been a problem so far.
The programming language of choice for building OS X gui applications is Objective-C with Cocoa, I would recommend that you check out some books on that. There are python bindings for Cocoa but they are not optimal.
You should check out previous questions looking for books on Obj-C and Cocoa.