×
SparkFun will be closed on Tuesday, December 24th, and Wednesday, December 25th, in observance of the Christmas holiday. Any orders qualifying for same day shipping placed after 2:00 p.m. (MST) on Monday, December 23rd, will be processed on Thursday, December 26th, when we return to regular business hours. Wishing you a safe and happy holiday from all of us at SparkFun!
Please note - we will not be available for Local Pick up orders from December 24th-December 27th. If you place an order for Local Pick-Up we will have those ready on Monday, December 30th.
Getting Started with GUI Python Development
If you're looking to make your own dashboard or slick graphical interface, Python can help you out with the Tkinter package.
While Python is generally thought of as more of a sequential language that is called from the command line, several frameworks exist that allow you to construct your own graphical user interface (GUI). This can be extremely helpful if you intend to make your own dashboard, build a Nest thermostat clone, control lights in your office, or display sampled data in an easy-to-read format. In the following tutorial, we give you an introduction to the Tkinter package that comes bundled with most Python installations:
Python GUI Guide: Introduction to Tkinter
August 13, 2018
Tkinter is the standard graphical user interface package that comes with Python. This tutorial will show you how to create basic windowed applications as well as complete full-screen dashboard examples complete with live graph updates from matplotlib.
While other Python GUI frameworks exist, like wxPython, PyQt and Kivy, Tkinter is easy to learn, comes with Python and shares the same open source license as Python. We recommend starting with Tkinter as a place to learn about GUI development (or for quickly prototyping your own dashboard!) and then moving on to another package if you feel you need something prettier or more powerful.
In the tutorial, we give you an overview of the widgets available in Tkinter, followed by a relatively simple example of a temperature converter application.
We then show how to read and control hardware using the RPi.GPIO package. This culminates in a final example where Tkinter is combined with Matplotlib to create a live dashboard that automatically updates with real-time temperature and light data.
If you have done any GUI development, can you offer any tips to people just starting out? What's your favorite GUI framework?
I would like to propose a tkinter wrapper for people just getting started (or for advanced programmers in a hurry). PySimpleGUI (www.PySimpleGUI.org) was developed with beginners in mind from the start.
It's easy to create GUIs and even enjoyable because the results are seen quickly. There is extensive documentation, demo programs, and a Cookbook, all designed to get a quick-start at programming GUIs.
On the TRS-80... I had a programming job in 1980 as a teenager. I wrote games and simulations for ways kis scould make money. It was sponsored by the local newspaper. They would cart the computers around from school to school, give their pitch on why having a paper-route was a great idea. And as a "treat" I guess, they would set up the computer and let the kids play on it. It was well before computers in the classroom was the norm. A lot of fun to get paid to program, even if it was #3.25 an hour! But a ton of work. I re-typed my programs from the screen into their DEC mini computer so I could get a print out.
Come on...My TRS-80 originally only had 4K programming space and we did some pretty nice UIs (remember Hangman?). I never understood why Radio Shack kept pushing us to upgrade to 16K.
That said, I'm having fun now with Python and RPis. Enjoyed your tutorial.
Hahahaha, that's awesome. Sadly, I'm slightly too young and missed the TRS-80 days (although I've heard plenty of stories!). Were there any frameworks available at the time, or was everything from scratch?
Thank you for the tutorial.
I highly recommend Kivy - at least for the applications that we use it for. At my company we are using it for in-house test equipment and have made roughly half dozen factory fixtures using it. It is used as a display of values and to accept user input and we have done a little bit of simple live graphics with it. For our use it has been rock solid.
Good suggestion, thanks! It seems that Kivy supports a lot of newer interfaces like smartphones and multi-touch.
You are correct in that Tkinter is certainly not a robust nor efficient framework. For a real deployment, one of the other packages you listed should be used instead (and for real deployment, Python may not be the best answer anyway). For a quick and dirty UI, Tkinter worked just fine, so I imagine for some home projects or fast prototyping, it's a viable solution.
As far as I can tell, Tkinter comes with all installations of Python 3 (on all operating systems), so I should have been more specific. It looks like it was Windows and possibly OS X with Python 2.x.
Hi Shawn!
Sorry I don't have time at the moment to go through your tutorial in detail (i.e. "proofread" it), but glancing over it, it looks pretty good (as usual!).
I notice a lot of similarity to Tcl/Tk which I've used extensively, though the last time was about 5 years ago (and, as they say, "I've slept since then") so don't recall the exact details. It's certainly a lot easier to do for "quick" programs than the more extensive GUI development systems used for many "professional" stuff. A major advantage of the latter is much more efficient use of computation resources - think much faster response times, and smoother "moving" stuff - though at the cost of very much more difficult development. (I remember looking at doing some stuff on my first 128K Mac back in about 1985 or so -- it was horribly daunting, and I gave up!)
Anyway, thanks for the tutorial!
My understanding is that Tkinter is just a Python wrapper for Tcl/Tk, which would explain many of the similarities you might have noticed. You are correct in that many "professional" frameworks are more computationally efficient but require a much steeper learning curve.
I definitely appreciate the feedback!
So why does the world need a python wrapper for Tcl/Tk? How many levels of interpretation can a poor GUI stand before it collapses under the weight?
None of which is to say that there's anything wrong with the article, just raising a philosophical point about the product. I believe it was in Knuth's Art of Computer Programming that he mentioned a system running on 6-levels of interpretation (using 1970's technology!).
Curious, what are your thoughts on Python in general?
Which Python? It seems to me that the 2x/3x differences make them two different languages based on a common root (think American Southern English vs. British Cockney English).
Anyway, it's a Turing-complete language so it can eventually solve any computable problem. That makes it a "real" language, no matter what any haters may say.
Duck typing is a crazy dangerous thing in any language, especially in hard real time apps. It also seems to me to violate "Explicit is better than implicit". Since finding a defect gets approx 10x more expensive in each successive phase, I'd much rather have the language system catch the bug in the language translation phase than to have to wait until the execution phase (possibly while the app is in use for real) for the operator to notice a bad type.
Soft machine-controlled garbage collection encourages sloppy data structure use with bad consequences for hard real time apps. This has been true from LISP to java to Python.
Interpretive soft machines are slow (and occasionally buggy) in any language and especially unsuited for hard real time apps. They also have compatibility issues between different versions, sometimes unintentional, sometimes deliberate. I've seen this from UCSD Pascal to Python 2x/3x.
I know there's PyPy, but that's a JIT. I want my code compiled far in advance so it can be checked, checksummed, packaged, etc. Cython does not get completely away from interpretation.
The OO is nice to have, haven't made up my mind on AO. The latter seems too much like throwing some of your code over the fence to be implemented in a less-robust language, but I haven't used it enough to see if that's actually true
Overall, I'd have to say that Python's really not for me, since I do mostly hard real time (in case you haven't guessed), but if someone else likes it, I'm not going to complain.
My comment wasn't so much about Python, it was about adding another layer of interpretation to an already interpreted graphics package. I'd have said the same thing if it was a java or Visual BASIC or C# wrapper.