Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kivy – a cross platform Python UI framework

kivy.org

Post reply on HN
Print view View original

21–30 of 107 posts

Re: Kivy – a cross platform Python UI framework

#21

Post by dheera »

BiteCode_dev wrote: post #19
cglong wrote: post #7

The landing page is weird; it talks more about the funding for the framework than the framework itself. There's only one image showing UI, and the way its styled (cropped, tilted) makes me think its a stock photo, not a screenshot. The stock photo of a train right underneath isn't helping this perception for me. If you got as lost as me, the Gallery is accessible via a link at the top: https://kivy.org/gallery.html

Note that those are not stock widgets. 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.

I prefer Python as a language but JS is much easier to package dependencies and ship a finished product.

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
etc. while coexisting in the same shell environment as something else that wants different versions.

Re: Kivy – a cross platform Python UI framework

#22

Post by graemep »

goffi wrote: post #15

There is a galaxy of projects around Kivy, such as https://github.com/kivy/python-for-android to compile python project for Android (with Kivy or not) or https://plyer.readthedocs.io/en/latest/ for cross plateform API (notifications, hardware, filechooser, etc). 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 fra…

I used Kivy once a few years ago for a device that had strict constraints on what it could run with the requirement to run the same code on desktop too (to display the same data). It worked very well for that.

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.

Re: Kivy – a cross platform Python UI framework

#23

Post by serial_dev »

One cross platform Python framework I found interesting is flet https://flet.dev/

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.

Re: Kivy – a cross platform Python UI framework

#24

Post by graemep »

bbor wrote: post #14
jb1991 wrote: post #8

Earlier quoted context omitted.

> this is most European website I’ve ever seen. I couldn’t tell you exactly why… perhaps it’s the train subconsciously affecting me. Actually the train on that page is from Japan.

I recently learned that Ireland isn’t really in Europe according to some Irish people, so I think this is final straw: I’m adding Japan to Europe. We may lack the technology to make it a physical reality (yet!) but their recent history and culture are quite European. I wish they were an option for emigration in a post-P2025 world, but AFAIK they are not at all interested in asylum seekers, American or otherwise ;(

Really? Where do they think it is? yes, its an island but no-one says Japan (or Sri Lanka, or Java) is not in Asia!

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.

Re: Kivy – a cross platform Python UI framework

#25

Post by graemep »

ranger_danger wrote: post #6
bbor wrote: post #3

A) this is most European website I’ve ever seen. I couldn’t tell you exactly why… perhaps it’s the train subconsciously affecting me. 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…

I think a lot of people dislike html/web-based apps, and they are not as responsive in some cases as well. I have seen some mobile browser implementations that explicitly put large delays (hundreds of ms) into their touch handlers for example. You can see a similar delay in a side-by-side comparison video here https://www.youtube.com/watch?v=Z4CwVN9RRbE

" I have seen some mobile browser implementations that explicitly put large delays (hundreds of ms) into their touch handlers for example."

Why would they do that?

Re: Kivy – a cross platform Python UI framework

#26

Post by heavyset_go »

goffi wrote: post #15

There is a galaxy of projects around Kivy, such as https://github.com/kivy/python-for-android to compile python project for Android (with Kivy or not) or https://plyer.readthedocs.io/en/latest/ for cross plateform API (notifications, hardware, filechooser, etc). 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 fra…

I believe Qt's offering of Qt for Python/PySide6 even uses python-for-android in their android-deploy utility[1].

[1] https://www.qt.io/blog/taking-qt-for-python-to-android

Re: Kivy – a cross platform Python UI framework

#27

Post by kennydude »

cglong wrote: post #7

The landing page is weird; it talks more about the funding for the framework than the framework itself. There's only one image showing UI, and the way its styled (cropped, tilted) makes me think its a stock photo, not a screenshot. The stock photo of a train right underneath isn't helping this perception for me. If you got as lost as me, the Gallery is accessible via a link at the top: https://kivy.org/gallery.html

Yeah the stock photography feels really off to me as well and not really helping show off what the project is. Strange vibes

Re: Kivy – a cross platform Python UI framework

#28

Post by mardifoufs »

heavyset_go wrote: post #26
goffi wrote: post #15

There is a galaxy of projects around Kivy, such as https://github.com/kivy/python-for-android to compile python project for Android (with Kivy or not) or https://plyer.readthedocs.io/en/latest/ for cross plateform API (notifications, hardware, filechooser, etc). 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 fra…

I believe Qt's offering of Qt for Python/PySide6 even uses python-for-android in their android-deploy utility[1]. [1] https://www.qt.io/blog/taking-qt-for-python-to-android

It's pretty new though, and it's a bit rough around the edges still. The other issue is that almost every single package/library for pyside6 only supports QtWidgets, not QML. Meaning you wouldn't be able to use tons of libraries that make up the python qt ecosystem (for example, pyqtwidgets or vispy). Not a huge dealbreaker but it's something to keep in mind.

Re: Kivy – a cross platform Python UI framework

#29

Post by BiteCode_dev »

dheera wrote: post #21
BiteCode_dev wrote: post #19

Earlier quoted context omitted.

Note that those are not stock widgets. 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.

I prefer Python as a language but JS is much easier to package dependencies and ship a finished product. 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 etc. while coexisting in the same shell environment as something else that wants different versions.

This is especially true when you use a lot of tooling. I love jupyter, but installing it in a venv means pulling a lot of deps which will affect a lot what I can install.

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.

Re: Kivy – a cross platform Python UI framework

#30

Post by dheera »

BiteCode_dev wrote: post #29
dheera wrote: post #21

Earlier quoted context omitted.

I prefer Python as a language but JS is much easier to package dependencies and ship a finished product. 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 etc. while coexisting in the same shell environment as something else that wants different versions.

This is especially true when you use a lot of tooling. I love jupyter, but installing it in a venv means pulling a lot of deps which will affect a lot what I can install. 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. Unfor…

My ideal situation is that the system should maintain authoritative versions of every package and version that is ever requested, and they should not need to be shipped. Multiple versions of a package should coexist.

    /usr/lib/python3.12/torch/2.1.0/
    /usr/lib/python3.12/torch/2.1.1/
    /usr/lib/python3.12/torch/2.1.2/
When a package requests 2.1.1 it fetches it right out of there, installing from PyPI if it doesn't.

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?

Post reply on HN