For UI there is https://github.com/kivymd/KivyMD for Material design on top of Kivy.
And the team is nice (I've met some of them at PyCon or FOSDEM).
The framework is pleasant to use, and there is a descriptive language, kv, which is really great.
Cross compiling may be painful though (I did it for Android) and the app loading time is a bit long, but it's working.
Some things may be missing in comparison to big frameworks such as Qt, there is no WebView for instance, and accessibility is unfortunately not as good.
It's overall a very good project and it's a pity that it's not more known and used.
It was not an elaborate app, so I cannot comment on how well it might work with something bigger, but it worked very well for what I needed.
No mentions on the site at all. I only found this https://github.com/kivy/kivy/issues/8596 so seems like not yet implemented.
Meaning Kivy is not yet a good choice for user-facing apps. It is so frustrating to see all the new UI frameworks and they fall apart if you just ask about accessibility features that should be absolute standard in 2024.
If you got as lost as me, the Gallery is accessible via a link at the top: https://kivy.org/gallery.html
And that's one of the main show stopper for me with kivy: it comes with very few built-in UI controls, so you have to code a lot of things yourself.
I much prefer Python to JS, but things like react native win because of the community libs you can install save you tons of time, and produce a better result.
Python is a big fat conda-docker-shitshow because it doesn't provide a way to do
import tornado==5.1.2
import torch==2.1.0
None of the screenshots under the gallery are compelling or even acceptable these days.
Electron thus far seems to be the king of “desktop” ui.
For people that want to use the webstack, yes. But that's not everyone.
A fast, fairly simple GUI system thats GPU accelerated is pretty rare
even rarer if you want python support.
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
It's powered by Flutter behind the scenes and familiar enough so that you can translate most things from Flutter/Dart tutorials to Flet.
I haven't used it and I'll most likely never will (Flutter developer trying to pivot to real native development), but it seems to have an active community, and in theory, it enables developers to write relatively nice looking apps with a very popular language.
RIP Bram.
[1]: https://github.com/vim/vim/blob/master/runtime/syntax/kivy.v...
Most impressively, it was running very well on a first generation iPad, not to mention Android tablets, and of course, Mac, Windows, and Linux workstations.
It was ultimately dismissed by the stakeholders because there was no way to render a web page inside the App, which was something kivy couldn't do back then.
From a packaging point of view Kivy is not great.
For stuff that I'm likely to share with others, I've been moving over to Flet, because it lets me build things like webapps and stand-alone Windows apps. Both of those things can eliminate the hassles of installing Python apps as experienced by non-programmers.
I hate writing GUI code, and in both cases have written crude wrappers that let me throw together a functional dialog with tolerable defaults for everything. This approach works for "programmers who shouldn't trust themselves to write GUI's," similar to the old Visual Basic.
If ever I decide to leave tkinter, I think a viable alternative I will try is free-pascal[1]. It's a more comprehensive and well-thought toolkit for creating GUIs, more importantly it is also open source and cross-platform. It's the FOSS version of Delphi IDE.
Building data-centric cross-platform apps while staying (mostly [1]) within a single language ecosystem should be less friction and overhead than juggling multiple universes via API's, different runtimes and what not.
What kind of apps would benefit from this "single language" approach? For sure not the more open ended, exploratory data science type tasks. These are better delivered via notebook workflows, which, besides flexibility, enable better reproducibility and auditing. Also probably nothing that requires high performance interactive graphics.
But while not solving all UI problems for all people, there should be still plenty of relevant use cases where simplicity and fast prototyping give Kivy an edge when the task is to make algorithms and related tools available to non-technical users.
[1] ofcourse the actual number crunching might be done by yet another layer (typically C/C++) but that layer is essentially hidden from the data orchestation and UI integration that would be the Kivy app focus.
It feels like it's at the wrong level of abstraction for... basically everything.
The Pong game demo is an example of this: if you're writing a Pong clone (or most video games) where you're going to be operating on a canvas, you don't need all the widget infrastructure that Kivy offers--you're better-served by something like PyGame.
On the other hand, if you want to build a UI using standard widgets, the widgets they provide out of the box aren't particularly fully-featured or even good--you end up doing a lot of hand-coding of functionality that could be included, and the defaults aren't particularly desirable, so you end up having to configure a lot of, for example, visual display settings.
As another user pointed out, their default widgets don't support accessibility meaningfully, and there are many other features, such as dark mode/color scheme support, which modern users expect and which you'll have to code yourself. Realistically, a lot of clients aren't going to give you funding for accessibility features, so the defaults are what most projects will end up with, and if it's me developing it, I'm doing accessibility on my own time, so I'd want this to be configuring what's largely already there, as opposed to what Kivy has: implementing it from scratch. In 2024 I'd view failing to support accessibility reasonably out of the box, as almost a moral failing, and certainly this is enough to discount Kivy from being used for any product intended to go to production.
There IS a fairly vibrant ecosystem of 3rd-party widgets (flowers; there's a "garden" metaphor in their branding for the ecosystem). But this comes with all the problems of a 3rd-party ecosystem: Kivy itself is probably large enough that it won't become abandonware in the forseeable future, but 3rd-party projects aren't, and there are large security and reliability risks to pulling in a bunch of small packages maintained by developers of various talent, intention, and funding. These are risks you generally have to accept for something unusual, but you shouldn't have to accept these risks for your bread-and-butter widgets like buttons and dropdowns.
If you're embarking on a project that benefits from using pre-built widgets like this, the framework I'd recommend is Flet. My experience with it has been overwhelmingly positive, and I've entirely switched away from PyQt for any new projects. The one criticism I'd give is that it doesn't really support multi-window, but that's something I'd avoid for most projects because multi-window support can never really be cross-platform, since mobile platforms don't really support windows as such.
> https://github.com/kivy/kivy/issues/8557
This issue has been unresolved for half a year now.
web, mobile etc. react paid my rent but never again.
Hopefully, we can have that someday, without the likes of Electron or whatnot.
I would like to write a react app, with all its progress in UI/UX and thousands of libraries, package them into a Python app and distribute it as a desktop application.
https://pywebview.flowrl.com https://pyinstaller.org/en/stable/
Python dev considering Electron vs. Kivy for desktop app UI - https://news.ycombinator.com/item?id=39889274 - March 2024 (9 comments)
Python app development for beginners – Kivy mobile app tutorial - https://news.ycombinator.com/item?id=26935529 - April 2021 (9 comments)
Kivy: Cross-Platform Python Framework for UI Development - https://news.ycombinator.com/item?id=25484451 - Dec 2020 (55 comments)
An update on Python-for-android: v2019.06.06 released and future plans - https://news.ycombinator.com/item?id=20133966 - June 2019 (7 comments)
Kivy 1.10.0 released - https://news.ycombinator.com/item?id=14297890 - May 2017 (33 comments)
Python for Android - https://news.ycombinator.com/item?id=13964561 - March 2017 (61 comments)
Kivy: Develop multi-touch enabled Python apps - https://news.ycombinator.com/item?id=12127158 - July 2016 (45 comments)
Kivy 1.9.1 released - https://news.ycombinator.com/item?id=10827322 - Jan 2016 (22 comments)
Python on Android - https://news.ycombinator.com/item?id=9482618 - May 2015 (49 comments)
Kivy 1.9 – A framework for creating novel and performant user interfaces - https://news.ycombinator.com/item?id=9315404 - April 2015 (16 comments)
Kivy – Open-source Python library for rapid development of applications - https://news.ycombinator.com/item?id=8181306 - Aug 2014 (47 comments)
Python on Android? First impressions of Kivy - https://news.ycombinator.com/item?id=4677863 - Oct 2012 (10 comments)
Kivy - Open source cross-platform library for rapid development - https://news.ycombinator.com/item?id=4601016 - Oct 2012 (23 comments)
Kivy: python UI framework. GPU accelerated, multi-input (win,osx,lin,android) - https://news.ycombinator.com/item?id=2773488 - July 2011 (18 comments)
2) this is first time I’ve ever seen mobile included as part of “Cross-Platform”, that’s pretty awesome. We’re living in the future, friends! Tho it also makes me shudder at the thought of the phrase “QT app development”…
III) At this point, why not just use web? What is a “truly cross platform UI framework” other than HTML? I’m currently developing a site that uses TS in the frontend and Python in the back, and that seemed like a nice Unix-y division of labor. What am I missing?
Well, Flet's landing page has a bunch of features and benefits. What is an "enormous risk" anyway? Depends on what you're doing. There are endless cases I can imagine where I just don't care at all about such a risk.
It's somewhat of a niche project, and certainly not for everyone, or for every project, but it's an active project with some real users.
Feels like a similar kind of energy, but your scenario is easier: if it goes away they could find new maintainers or take it up themselves.
As I see, you can use pure python packages, but not Flutter packages or Python packages with some other languages in the mix.
Actually the train on that page is from Japan.
nice, I love casual exceptionalism in the morning.
> At this point, why not just use web
Because not everyone uses a "web stack". Moreover trying to learn a webstack is pretty hard. Sure JS is easy, but everything on top to make it more "productive" changes every 6 months. I mean yeah I could just use react, but Urgh, its nasty.
However the killer issue issue is hardware acceleration. Its possible to get kivy running at 60 FPS on a pi3. getting something to run at 60fps on web for the pi3 is bloody hard. Even though its python, it runs really fast, something not really possible in the browser.
In other words: how would that demo hold up if you asked them to recreate some popular react libraries, such as tables, graphs, and 3D simulations? When dealing with hard tasks (and network latency!) it seems like any platform-level delays would be quickly dwarfed by context-specific delays. And in the latter case, I’d rather have NPM than https://kivy.org/gallery.html !
PS did anyone else know NPM is now owned by Microsoft? We seriously need a revolution, or at the very least a figurative corporate guillotine. They own most of gaming, most of NLP/AI, most of dev tools, most of business/office computing, most of the OS market in general, most of… everything, it seems like. I’m just thrilled in hindsight that the windows phone failed!
Why would they do that?
Everything is GL accelerated, so the UI is snappy and fast.
I have known a lot of Irish people (I mean either over here in the UK temporarily or first generation immigrants) and I have never heard anyone say that.
Do you know of anything major that's using it?
Everything else has subtle differences, and yes, your users will notice. You may as well just ship a janky Electron app like Teams. But if you want to impress your users with a native feel, it's the Apple toolkits or nothing.
Fortunately the Python community is much more serious about making deps that work together than the JS community, and the fact it works at all given the cartesian products of all the python modules is kind of a miracle and a testament to that.
Unfortunately, that's a problem that is unlikely to be solved in the next decade, so we all live with it.
The reverse problem is true for JS, and I see many projects shipping very heavy frontend code because despite all the tree shaking, they embed 5 times the same module with different versions in their bundle. That's one of the reasons for the bloated page epidemic.
I guess it's a trade-off for all scripting languages: choosing between bloat or compat problem. Rust and Go don't care as much, and on top of that they can import code from 10 years ago and it sill works.
However, and while I do know how hard it is to ship python code to the end user (at least if you don't use a web app), I don't think the version problem is the reason. We have zipapp and they work fine.
No the main reason iscompiled extensions are very useful and popular, which means packaging is solving more than packaging python, but a ton of compiled languages at one. Take scipy: they have c, pascal and assembly in there.
This can and will be improved though. In fact, thanks to wheels and indygreg/python-build-standalone, I think we will see a solution to this in the coming years.
I'm even betting on astral to providing it.
/usr/lib/python3.12/torch/2.1.0/
/usr/lib/python3.12/torch/2.1.1/
/usr/lib/python3.12/torch/2.1.2/
The same should be true of JS and even C++. When a C++ app's deb package wants libusb==1.0.1 it should NOT overwrite libusb-1.0.0 that is on the system, it should coexist with it and link to the correct one so that another app that wants libusb-1.0.0 should still be able to use it.
> Fortunately the Python community is much more serious about making deps that work together
This is very not true at least in ML. I have to create a new conda environment for almost every ML paper that comes out. There are so many papers and code repos I test every week that refuse to work with the latest PyTorch, and some that require torch<2.0 or some bull. Also, xformers, apex, pytorch3d, and a number of other popular packages require that the cuda version that is included with the "torch" Python package matches the cuda version in /usr/local/cuda AND that your "CC" and "CXX" variables point to gcc-11 (NOT gcc-12), or else the pip install will fail. It's a fucking mess. Why can't gcc-12 compile gcc-11 code without complaining? Why does a Python package not ship binaries of all C/C++ parts for all common architectures compiled on a build farm?
> I have to create a new conda environment for almost every ML paper that comes out
That's how it's supposed to work: one env per project.
As for the rest, it's more telling about the C/C++ community building the things bellow the python wrappers.
But what I really hope is that they'll tackle the user app shipping problem eventually.
Pick one package source. Stick with it. And don't import every 0.0.x package from that package source either.
There are obviously reasons to use more than one package source, but those reasons are far rarer than a lot of inexperienced devs think they are. A major version number difference in one package isn't a good reason to complicate your build system unless there are features you genuinely need (not "would be nice to have", need).
So say you want to add pytorch, with GPU acceleration if it's possible on a platform. You want to make it multiplatform to some extent. You can't add another index if you want to use vanilla build, as that's not allowed. You can add a direct link (that's allowed, just not an index) but that's going to be specific to a platform+python version. Pytorch doesn't even provide CUDA packages on pypi anymore (due to issues pypi), so you need to be able to use another index! You'd need to manually create requirements.txt for each platform, create a script that packages your app with the right requirement.txt, and then do it again whenever you update. Otherwise, I think the most recent advice I've seen was to just make... the user download the right version. Mhmmmm.
The other option is to use poetry or something like that, but I just want to use "python build . "...
At this point, venvs are the best workaround, but we can still wish for something better. As someone commented further up, being able to “import pytorch==2.0” and have multiple library versions coexist would go a long way.
That causes 50 copies of the exact same version of a 1GB library to exist on my system that are all obtained from the same authority (PyPI). I have literally 50 copies of the entire set of CUDA libraries because every conda environment installs PyTorch and PyTorch includes its own CUDA.
I'm not asking the OS to maintain this, but rather the package manager ("npm" or "pip" or similar) should do so on a system-wide basis. "python" and "pip" should allow for 1 copy per officially-released version of each package to live on the system, and multiple officially-released version numbers to coexist in /usr/lib. If a dev version is being used or any version that deviates from what is on PyPI, then that should live within the project.
I basically agree with this. With the caveat that programs should not use any system search paths and packages should be hardlinked into the project directory structure from a centralized cache. This also means that a dev version looks identical to a centralized version - both are just directories within the project.
Yes, it would be nice to have that by default.
In fact, it's what uv (https://github.com/astral-sh/uv) does, and one of the reasons it's so fast and became so popular so quickly.
Astral for the win.
Also, Windows is my primary dev environment. Any solution must work cross-platform and cross-distro. Telling everyone to use a specific distro is not a solution.
Nix fans are becoming as obnoxious as Rust fans. And I say that as an times annoying Rust fan.