I'm trying to make terminal user interface with python which I will use it as post installation script for min linux os. But I don't want to use ncurses or urwid because it feels like overkill. I'm looking more in whiptail or screen direction. But I don't know is it better to call ui terminal rendering from python subprocess or to use it with python bindings like pythondialog, here are the reasons for my doubts.
Is whiptail/screen available on every minimal linux image... subprocess should be better suited for my program.
pythondialog requires installation of python3-dialog package. Since I want to make a postinstallation program for linux min image I want to use dependencies as little as possible.
What would you suggest for my problem?
Maybe npyscreen is what you are looking for, but i havent tried it. It just installed for me in fresh 2.7 virtualenv with zero dependencies - EDIT: sorry no, it runs on top of ncurses.
I've had a similar notion about ncurses or urwid. You might want to try:
prompt toolkit - focus on UI, comes with tons of examples
asciimatics - handy for UI and animations, also with a bunch of helpful examples
Both have a responsive and active community.
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.
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.
I have read that it is possible to build GTK+ on MacOS X. I know that it's possible to create a bundle of a GTK+ application on MacOS. I also know that it's possible to create widgets that look sort of native. However, searching around I am not really clear on how to create a bundle that includes the native theme stuff, and uses Python rather than its own C main-point. There are also rumors that it's possible to build PyGTK, but it sounds like there might still be some wrinkles in that process.
However, there is no step-by-step guide that explains how one can set up an environment where an application might be run from Python source, then built and deployed in an app bundle. How can I go about doing that?
Native looking widgets is quite complicated.
There's a beginning of quartz engine (for theming) found here http://git.gnome.org/browse/gtk+/tree/gdk/quartz
For self-contained applications check out the newly released bundle on http://live.gnome.org/GTK%2B/OSX
I'm not sure if I'm grokking all the details of your question, but looking at your problem in general (how do I deploy a python app on mac), I'm inclined to say that the answer is py2app. Basically this will bundle a python interpreter and all relevant python files for you, and give you a scriptable system that you can use to add in whatever other resources/dependencies you need.
While it's not a guide solely targetted at python/GTK+/OS X, this post is a good, detailed description of someone else's attempt to do most of what you describe. Obviously, the app-specific stuff is going to vary.
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.