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

51–60 of 107 posts

Re: Kivy – a cross platform Python UI framework

#51

Post by dheera »

BiteCode_dev wrote: post #45
dheera wrote: post #30

Earlier quoted context omitted.

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…

I'm assuming by system you mean OS, which is a terrible, terrible idea. Dev stack and system libs should not coexist, especially because system libs should be vetted by the OS vendor, but you can't ask them to do that for dev libs. > 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+…

> one env per project

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.

Re: Kivy – a cross platform Python UI framework

#52

Post by bofaGuy »

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.

But you can do that, obviously not with this syntax. It’s non standard but I have built programs that install all dependencies as a first step. It’s pretty trivial.

Re: Kivy – a cross platform Python UI framework

#53

Post by bartekpacia »

bmitc wrote: post #50
cardanome wrote: post #9

So how is the accessibility story? 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.

Is there a cross-platform accessibility library? I can tell you that developing a cross-platform GUI framework is a gigantic can of worms fraught with forced yakshaving, no documentarion, no support, and endless bugs across the stack even down into the OS and GPU driver stack. So in my opinion, everyone asking for accessibility features on every GUI framework announcement should get together and make a GLFW for acces…

Sounds like AccessKit [0] to me

[0]: https://github.com/AccessKit/accesskit

Re: Kivy – a cross platform Python UI framework

#55

Post by mardifoufs »

heavyset_go wrote: post #40
mardifoufs wrote: post #28

Earlier quoted context omitted.

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.

Yeah, it seems pretty half-baked at the moment. It looks like QML is the intended target for mobile apps on the Qt side.

Yep I don't think there's a practical way to use qtwidgets on mobile, so it's not like Qt is treating pyside differently. It's just that the ecosystem doesn't really follow. I wonder if that's different on the c++ side. Is QML more prevalent in the c++ qt ecosystem?

Re: Kivy – a cross platform Python UI framework

#56

Post by forrestthewoods »

dheera wrote: post #51
BiteCode_dev wrote: post #45

Earlier quoted context omitted.

I'm assuming by system you mean OS, which is a terrible, terrible idea. Dev stack and system libs should not coexist, especially because system libs should be vetted by the OS vendor, but you can't ask them to do that for dev libs. > 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+…

> one env per project 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 s…

> but rather the package manager ("npm" or "pip" or similar) should do so on a system-wide basis.

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.

Re: Kivy – a cross platform Python UI framework

#57

Post by BaculumMeumEst »

serial_dev wrote: post #23

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…

Why do people keep doing things like investing in a framework, written by one set of developers, built on another framework, written by another set of developers, and acting like that is not insane? Unless both stacks are written by huge software companies that have an extreme vested interest in keeping them running, there is a huge risk of abandonment. Maybe Google just decides maintaining flutter is a pain in the ass and React Native is just good enough. Maybe the flet devs don't turn enough profit. Maybe flutter changes too radically and makes it difficult for flet to catch up. Such situations have happened again and again and again, and they will continue to into the future. What are we gaining here that is worth such an enormous risk?

Re: Kivy – a cross platform Python UI framework

#58

Post by bomewish »

forrestthewoods wrote: post #56
dheera wrote: post #51

Earlier quoted context omitted.

> one env per project 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 s…

> but rather the package manager ("npm" or "pip" or similar) should do so on a system-wide basis. 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.

Are you just describing something close to Nix?? In any case, Nix solves a lot of these problems.

Re: Kivy – a cross platform Python UI framework

#59

Post by forrestthewoods »

bomewish wrote: post #58
forrestthewoods wrote: post #56

Earlier quoted context omitted.

> but rather the package manager ("npm" or "pip" or similar) should do so on a system-wide basis. 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.

Are you just describing something close to Nix?? In any case, Nix solves a lot of these problems.

Kind of, but not really. Nix is extremely complicated. Programs / projects including their dependencies is exceedingly simple.

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.

Re: Kivy – a cross platform Python UI framework

#60

Post by kerkeslager »

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.

The problem I see a lot of JS developers having when they start using Python is they try to do the "import the entire world" strategy of development that's common in JS, and there isn't good tooling for that because Python just doesn't have that culture. And that's because it's a bad idea--it's not a better idea in JS, it's just more part of the culture.

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

Post reply on HN