Kivy – a cross platform Python UI framework

And it doesn't provide any way to use a link to any other package repository if you want to stick to vanilla pyproject.toml + build (the official build tool). So if you want to use the CUDA or rocm version of torch, for example, you have to add a direct link to the package. That means that you'd have to hardlink to a platform specific version of the package. There's no way to just make a package look at a non pypi repository to get the version you want otherwise.

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 . "...

I think it was something to do with dealing with double taps. Either way, the delay has been removed for about as long as that videos been up.

https://trac.webkit.org/changeset/191072/webkit

This delay can be worked around by using the standard viewport meta tag, which any web app built for mobile will be using.

I wrote a app to communicate with a medical device in 2018. Was published on Apple AppStore and Android PlayStore

https://rvier.fr/images/chronomonitoring.png

I've kept an eye on Kivy for quite a while and prototyped a bunch of projects over the years with it, and I'm not a big fan.

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.