PysimpleGUI
github.com
github.com
I messed with Tkinter but was struggling for awhile just getting it to look…nice. I stumbled on PySimpleGUI and suddenly I was flying. Setup the hooks to the Jira api and I had what I wanted. Was a great project to learn UI development.
They told us they'll start doing this at my job. I started looking for a new one.
A friend of mine told that one of his jobs he developed simple internal Qt client to perform basic tasks in Jira.
And when I was required to track my tasks in Jira I created a bunch of custom console scripts make all changes via https://github.com/go-jira/jira .
I do wonder why don't we see more "automatic" GUIs: given some data structures and functions, make a passable interface to interact with them. Use heuristics to pick when a panel should be vertically or horizontally laid out, or placed in a tabbed interface, or a popup, etc. It would unlock a lot of functionality that is too nested for CLI and too "native" for web apps.
> Gooey - Turn (almost) any Python 3 Console Program into a GUI application with one line
There was something answering that description a couple decades ago, called Naked Objects. Never tried it because I wasn't into Java, but it sounded useful.
For example, you can write:
``` import arsd.minigui;
void main() { // need to define the data you want in a struct, // it requires a struct even if you only want one item struct Data { string code; }
// then do the dialog function with the struct and it // auto-creates a dialog for all the parts of the struct // and calls the function you provide when the user hits OK dialog((Data received) { // you got the number here
messageBox("You gave me " ~ received.code);
});
// need to run the event loop explicitly so main doesn't return
// early and end your program; this will return when all windows are closed
EventLoop.get.run();You can also attach some user defined attributes to tell it which widget you want to control the thing (defaults are line input for string and int, drop-down select for enum, groups for structs... that's about all i bothered to implement so far, tbh my gui toolkit is more of a side project toy than a main event so the time i put in is limited), for example using `@ControlledBy!VerticalSlider(0, 100)` on an `int` to make it a slider from 0 to 100 instead of a text box asking for a number.
My menu thing uses this too, you can attach functions to menus and it can pop up a dialog. For example you might do `@menu("Search") Find(string text) { ... }` and let it auto-generate the menu and dialog box for it. I also have a `DataControllerWidget` which does the callback on any change event, allowing for real-time manipulation. I wrote a little blog post about this a couple years ago (seriously, i move sooooo slowly on this stuff!) http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...
I'd love to spend more time on this, I think it is really cool, but tbh I haven't gone too far beyond the basics and since day job has no use for such stuff it gotta be squeezed into when i feel like doing code on the weekend.
While native UI are always best for performance etc, I’ve always found them harder to style than a webpage.
What is the equivalent of components (listed of styled components that go together) in python GUI? Something like for Flutter or SwiftUI, that look slick without much effort.
[0] https://raw.githubusercontent.com/PySimpleGUI/PySimpleGUI/ma...
I hate the new generation of UIs: acres of whitespace, buttons that don't look like buttons, disappearing scrollbars, hamburgor menus.
I recently tried overwatch and I seriously cannot find a single damned thing in that UI.
Unlabelled buttons. Shit in completely random places. Extra buttons where not needed just to insert ridiculous white space. Components that don’t have functionality you expect, which is only granted by happening in to the similar component from a different pathway.
What an utterly idiotic UI. If you are a manager at blizzard, please fire these bone heads that did this.
It also adds to the already crippling cost of software development. The words you dread to hear from marketing: "Our software looks old."
There was software like this in the 90s, but it's not the 90s aesthetic people usually talk about. A lot of work went into the design of Windows 95's user interface.
They also give built in separation of frontend and backend, and the option of remote access should you later need it.
Plus, you can use them just like a native app: Just make a tiny minimal tkinter or similar kind of GUI, that just has an "Open browser UI" button.
You can even secure it against daemons running as other users on the same machine, by having the launch button put a token in the URL, but I haven't seen this done anywhere.
I did something like that in an old job, except it was a much thinner wrapper around PyQt (and surprisingly little code). A key difference is that setting properties/signals and nesting widgets was done together. One benefit of that over setting properties in the constructor is that, if you need a name for a widget (e.g., to set the text later), you can still set the properties of it in the main bulk of the view.
self.mytext = QTextEdit()
view = {
"title": "My Window Title",
QVBoxLayout(): {
self.mytext: {
"text": "Initial text",
},
QPushButton(): {
"text": "copy from self.mytext",
"clicked": self.copy_text,
}
}
}
setup_view(self, view)
It feels that way to me too but that change was introduced in Python 3.7, which is over five years old now!
https://docs.python.org/3/whatsnew/3.7.html#summary-release-...
I have to admit, the alternative method used in the second example is interesting, it's probably just as good as my suggestion in most ways. But ape4's quote about dictionaries still doesn't make sense to me (both on its own or in context in this conversation).
That means, avoid mutating widgets directly. Instead bind their properties to some data store that rerenders automatically on change. The input/output example on their page demonstrates something like this.
Nobody does getElementById() any more.
---
I lost a boatload of time on a project trying to get WxPython and WxFormBuilder to work together years back... any little change in the forms broke everything in the backend. I finally wrote a little shim that mated everything up, until I had to change a fields Type, and it broke everything. It appears that won't be the case here. (Thank goodness!)
I recommend users to install my Python programs with pipx (https://github.com/pypa/pipx). I think it is the best option when the audience is at all technical. pipx makes such a big difference for managing Python applications. It avoids the version conflicts of `pip install --user` and the pain of manually creating per-application venvs. In general, it provides a reasonable user experience. Because of this user-friendliness, I can recommend pipx as the primary installation method and expect people to succeed at installing the program with it. (I don't see issues about pipx installation in the trackers of projects that recommend it.) My programs have binary dependencies but no GUI.
Python absolutely sucks in this regard and I don't think there is a permanent solution. Except give python a compiler that can spit out binaries and libraries. I wish nim was 100% python code compatible.
Compiled binaries with shared libs work fine as long as they come from an OS package repository. Statically compiled binaries work almost everywhere. But a script that needs a bag of other specifically versioned scripts needs to live in it's own (sometimes impossible) world. Hell, I've even had a single pip install on a clean system fail because two dependencies of the module I was installing wanted different versions of some common dependency. Gah, burn it with fire.
I'm always amazed at the Windows ecosystem. I can download something that was built in the 90s and happily run it in wine.
I don't see Python packaging and dependency management as a bulldoze-everything-and-start-over disaster anymore. Thanks to improvements like wheels, manylinux, `pyproject.toml`, https://peps.python.org/pep-0517/, and Poetry/PDM/Flit/Hatch/etc. they are increasingly adequate.
I have compiled a Python application to a native binary with https://github.com/Nuitka/Nuitka. Once I got it to compile, it fully worked. The process was a little fiddly, although I don't remember the exact problem. In the end I set up a Docker container for the build, and then it built. Maybe Mojo will be what you wish Nim was.
For standalone scripts, there are options. (My list: https://github.com/stars/dbohdan/lists/python-scripts-with-d....) Support for scripts should be coming to pipx. I have used the development version and liked it. This is an area where things are actually pretty good but not common knowledge.
> I'm always amazed at the Windows ecosystem. I can download something that was built in the 90s and happily run it in wine.
Developing a desktop GUI framework for a single platform is relatively easy. Developing a cross-platform GUI framework for three or more platforms is extremely hard. And a lot of people would STILL ignore it if it's not "mobile first", targeting iOS and Android too (meaning that it's probably dogshit for desktop apps).
Is that really true outside of web devs?
https://github.com/hiAndrewQuinn/finstem
Mostly I'm wondering whether anyone else has ever done what I'm trying to do here. My tool has well defined CSV, TSV and JSON flags -- has anyone else ever tried to use an actual full CLI tool unchanged to build a GUI around? What challenges should I be ready to face?
So basically, treat the GUI as a stepping stone to helping the user build scripts/workflows around your CLI. That way you are only developing the CLI, and the GUI is just a helper app. The second you start adding features to the GUI that can't be done in the CLI, you are now maintaining two separate apps.
Check out the shortcuts in its dropdown menus.
The main challenges are the same problems you’d run into with multithreading, like deadlock where the GUI and CLI are both waiting on the other. So both sides typically need to be running their I/O in a separate thread from the “business logic”, so both sides remain responsive.
A second common issue is idiosyncrasies around each OS’s handling of pipes, things like making sure you flush the buffer, or just the different OS-level API calls that differ between Linux, Mac, and Windows.
[1] http://www.playwitharena.de/
[2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
Something is not right here. Either this is a joung enthusiastic coder, which is probably the case, or there is so much text in order to convince you to try it.
The readme even has an about me section where the author introduces himself.
For some examples, scroll to random points in the readme and read a few paragraphs, then repeat what you just read.
I've followed the project when I was in college and used it in my personal project.
I hope this one is not rude too: are you sure you're just not afraid of having to read stuff rather than being spoon fed bullet points and steps?
> Some programs are not well-suited for PySimpleGUI however. By definition, PySimpleGUI implements a subset of the underlying GUI frameworks' capabilities. It's difficult to define exactly which programs are well suited for PySimpleGUI and which are not. It depends on the details of your program. Duplicating Excel in every detail is an example of something not well suited for PySimpleGUI.
says absolutely nothing and gives the reader no useful leads as to the applicability of the framework to their project.
tl;dr: "you will be disappointed if you want to do something fancy"
(of course, should you want all three of (a) easy, (b) fancy, and (c) someone else has already done much of it for you, I'd bet you would be bound for disappointment anyway)
From "About Me" [1]
I've been writing software since the 70s. The majority of my career was spent creating products in Silicon Valley
You could have gotten the same idea across by saying something like "This is a visual project so I feel like it should include more screenshots in the main description" and leaving the insulting assumptions out entirely.
Some people actually enjoy reading about tools, rather than just looking at it from an entitled viewpoint of "what can I do to get this running as fast as humanly possible while reading as minimal words as possible". This is a tool that someone else wrote that you get to use for free, so stop whining and let them be free to express themselves as they see fit.
It is like if you name your project with the words Smart, Open, Trusted, Secure, etc etc, people will tend to point out that it doesn't meet it's name ideal.
Contrast with a project like C or BSD. What's the opposite of C? Nothing. Nobody can point out that "Hey, the C language doesn't live up to it's name" because it's name has no connotations or preconceptions.
I used it in all my college demo and small projects and I loved it. The most complex GUI that I made was a oscilloscope frontend for lab-made signal recorder. It is indeed a simplegui library.
You can even use pyinstaller to make a fake application using it.
I’d say it stops working so well if you want a ”modern” looking GUI, as the GUI looks pretty old.
Also, the documentation is really good imo.
Before I landed on this one I spent significant time testing/prototyping PyQt and TkInter. Those tools required more effort than I was looking for (based on expectations from past environments and tools for business app dev). PySimpleGUI is quicker and easier than the other tools and is powerful enough for my needs.
Other than the support for web UIs, this seems like Java AWT but for Python. It presumably has the 'lowest common denominator' problem of supporting only those widgets which are available in all the wrapped GUI toolkits.
For desktop UI work, why not just use Qt's official Python bindings? Qt has good cross-platform support, and its Python API seems very approachable.
https://doc.qt.io/qtforpython-6/quickstart.html#create-a-sim...
However, the framework’s author describes the usecase as building simple UIs for what otherwise would be used via the command line or for building UIs for cases when people can't or don’t want to learn a more complex framework (this could include HTML/CSS/JS, which is quite complex, if you do not know it yet!).
However, as soon as I discovered VS Code's serial monitor plugin I abandoned my project.
I would suggest using the "standalone" mode of Nuitka. As the name suggests, it is self contained, but it's a lot of files per program because all the C extension modules are separate files. It's tempting to use "onefile" model instead because it really is over for so seems neater, but this is really just a self extracting program with the same files hidden inside as standalone, so has a few issues like the other packagers (e.g. can trigger virus warnings or leave files lying around in temp directory).
I've mostly used PyQt5, and it's able to package that without any extra effort.
I use the "package it all into one file" option: it's a little slow to start, but for my purposes (primarily, longer-running applications) that's ok.
It depends on your requirements. I still produce actual native GUIs for tools I write. They're faster, require less futzing to service, generally continue working for years if not decades, have far richer control possibilities out of the box and tend not to rely on 5000 layers of excrement slapped on top of each other.
Oh and no fucking Javascript!
We tried this approach once, for this exact reason that we didn’t want an “old thick client”. Our app interacted heavily with the user’s OS and their line of business app, and it was a nightmare dealing with the customer’s IT department, wondering why we needed to run HTTP servers everywhere, causing security alerts.
We switched it to a simple Tkinter app and everyone involved was much happier.
PyInstaller is a good starting place. There are several others with similar capabilities.
And it will produce a single-file executable that bundles the interpreter, application Python code, extensions, and any other resources (data files, images, fonts, etc).
Both numpy and pytorch are explicitly supported, although that's not guaranteed for all extension packages.
However on Linux things kinda suck because PyInstaller will package your current interpreter, so if it's linked against things that are different on another Linux (eg no glibc) it will often crap itself. But so is the joy of distributing compiled software to Linux users :).
I typically use an older distribution as my build box: this means that the dependencies pulled in by the interpreter are older versions, and when it runs on a newer distribution, the backward compatibility for libraries will ensure it works ... usually.
I've messed about with using a completely independent build tree for this: something that depends on libc/libm/etc only from the OS, and all other dependencies are part of my build. That seems like it works pretty universally, but it's a lot of work.
I've been meaning to look into leveraging the Flatpak runtimes for this: they seem like they have pretty similar concerns.
No server admin work needed!
That can be mitigated with a token included in the browser launch URL, but it seems like a pretty unlikely vector anyway, someone would have to write code that specifically knows about SyncThing, and then convince you to install it, and then you'd have to not use password protection.
A webui for a desktop app can be made perfectly securely, though.
For example it can bind to 127.0.0.1, not do external network requests, and require a token (generated by a systray menu utility or an app shortcut for example) that will prevent automated exploits from accessing it as well as other users on a multi-user system.
* usable on pretty much any platform
* easy to distribute/update
* easily trustworthy/jailed (no need to install something that might access your data)
It makes me sad, but as far as I can see, there is no serious alternative for universal+jailed apps.
There are plenty of ways to distribute thick client apps that are usable from any client, easy to update, and which don’t have access to local resources, like Remote Desktop, VMware, Citrix, etc.
and ask your users to install those before being even able to use your app?
I haven't phrased my argument very neatly, but the point stands: anyone with an iphone/android/linux/… can easily use a web app, now, without any prerequisites. You don't have to bundle it or distribute it differently than with a webserver and it's a single codebase. That's not the case for any other tech that I'm aware, and it's a shame.
But it’s all about requirements. The benefits you describe are not universal benefits.
Mobile app stores, where users have to install apps, transact over a $1 trillion per year. Sometimes a native app provides a better experience.
Python GUIs for Humans – Transforms UI into People-Friendly Pythonic Interfaces - https://news.ycombinator.com/item?id=28600922 - Sept 2021 (43 comments)
Looks fine, works fine, API matches the C++ docs... slightly unpythonic at times but at least it's well documented.
I’ve encountered a few vendor apps over the years, like data collector apps, that I noticed were written in Python with Tkinter. The only way I knew was they hadn’t changed the default Tkinter icon.
I think you really have no idea what you’re talking about.
If you’re interested in Python desktop apps, check out TKinter. I have a piece of boilerplate code I typically start with [0], and within an hour I can have a finished piece of software that runs in the native windows manager on any OS with no libraries or frameworks to manage. It’s not the prettiest code but it’s very easy to write and I love how native it is.
[0]: https://gist.github.com/kylenahas/a07f2ce8ced689975eae56d6ea...
For browser web-based GUI, you can use nicegui[1]
>> Want to share your PySimpleGUI program with friends and family that don't have Python installed on their computer? Try the GUI front-end for PyInstaller that you'll find in the psgcompiler project.
If my software doesn't build on Windows, it's probably by design.
> 2023 is going to be the "Make or Break" year. I ultimately need to determine if the project is going to continue. To date, it's nowhere near sustainable. The income doesn't cover the cost of the project, meaning that it's not only unable to allow me to pay for my cost of living, but I continue to rack up debt, borrowing money, to keep the project functional.
> This isn't new information if you've followed the over 1,200 announcements I've made since Sept 2018. The data is available should you wish to look at the GitHub Sponsorships and do the simple math required to calculate income from Udemy. It would be great for the project to keep going. I'm hopeful, but more than hope's required to keep the project going.
So if you like this project and want to see it around in the future, please support it.
Github sponsors is probably the best place: https://github.com/sponsors/PySimpleGUI