[HN Gopher] Kivy - a cross platform Python UI framework
___________________________________________________________________
Kivy - a cross platform Python UI framework
Author : peanball
Score : 99 points
Date : 2024-07-06 16:27 UTC (6 hours ago)
(HTM) web link (kivy.org)
(TXT) w3m dump (kivy.org)
| mark_l_watson wrote:
| I wrote one iOS app using Swift and SwiftUI. Has anyone written a
| Kivy iOS app and pushed it to the app store, if so, please share
| experiences.
| eonpi wrote:
| Wrote a fairly complete POC in 2012 with kivy, it was able to
| render rather detailed floor plans, which was the most
| important feature of the POC since the idea was that, given the
| complexity, it should be written once and be able to run on
| multiple platforms with minimal changes, keeping in mind that
| mobile platforms were the priority.
|
| 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.
| mark_l_watson wrote:
| Thanks, I will try it out then.
| brvier wrote:
| 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
| mark_l_watson wrote:
| Thank you.
| bbor wrote:
| 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
| 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?
| ranger_danger wrote:
| 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
| cglong wrote:
| Kivy's marketing seems to be targeting LOB apps. If I was
| going to develop one of those, I'd optimize for something
| standardized and easy to maintain (HTML/JS) vs. the
| performance benefits of a native UX or cross-platform
| framework.
| bbor wrote:
| Thanks for the reply! If touch handler delays are intentional
| then it seems like an advantage, not a weakness -- who am I
| to disagree with UX experts employed by some of the top-
| paying tech companies or Mozilla? This is really a synecdoche
| of the overall situation, from my perspective: some really
| good devs want absolute control over every part of the stack,
| and to feel "close" to bare metal as they code, whereas the
| dummies like me appreciate that someone did a lot of the hard
| work for us.
|
| 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!
| graemep wrote:
| " 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?
| c-hendricks wrote:
| 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
| c-hendricks wrote:
| This delay can be worked around by using the standard
| viewport meta tag, which any web app built for mobile will be
| using.
| jb1991 wrote:
| > 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.
| bbor wrote:
| 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 ;(
| graemep wrote:
| 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.
| mig39 wrote:
| Does this work with JupyterlHub? Would be neat to try with some
| students currently learning Python with JupyterHub.
| cglong wrote:
| 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
| BiteCode_dev wrote:
| 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.
| dheera wrote:
| 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.
| BiteCode_dev wrote:
| 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.
| dheera wrote:
| 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?
| ericjmorey wrote:
| ML researchers might be thinking that their paper will be
| obsolete next month so why bother taking time to make
| their coding environment reproducible.
| BiteCode_dev wrote:
| 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++
| community building the things bellow the python wrappers.
| dheera wrote:
| > 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.
| ericjmorey wrote:
| I'm hopeful the uv will bring us closer to tooling on par
| with other language ecosystems. But it's very early on in
| the process.
| BiteCode_dev wrote:
| Given the track record they got, I'm confident they will.
|
| But what I really hope is that they'll tackle the user
| app shipping problem eventually.
| mardifoufs wrote:
| 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 . "...
| bmitc wrote:
| Poetry at least helps with that for Python. It's all still
| a mess though.
| bofaGuy wrote:
| 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.
| kennydude wrote:
| Yeah the stock photography feels really off to me as well and
| not really helping show off what the project is. Strange vibes
| cardanome wrote:
| 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.
| dec0dedab0de wrote:
| I think first tried Kivy in 2013, I wouldn't call it new.
| gostsamo wrote:
| I've heard some good things about beeware, but haven't tested
| it myself, so not sure. Most people I know use either qt or WX
| python.
| bmitc wrote:
| 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 accessibility libraries
| so that it can indeed be standard.
| winrid wrote:
| FWIW JavaFX is still great too BTW. I have a decent sized app
| that'll run fine with a 50mb heap, and you get native OS
| installers too. No web support though.
| victor106 wrote:
| Does it appear native? And I keep hearing that even though
| swing is really old, it has better performance and that it's
| used by IntelliJ. Not sure though
| brnt wrote:
| Funniest thing about Swing is that if you theme it (because
| you need to), you can make it look just as out of place (but
| modern!) as any Electron GUI.
| layer8 wrote:
| Yes (to a reasonable approximation), after calling:
| UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassN
| ame());
|
| (https://docs.oracle.com/javase%2Ftutorial%2Fuiswing%2F%2F/lo
| ...)
| goffi wrote:
| 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 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.
| graemep wrote:
| 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.
| heavyset_go wrote:
| 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
| mardifoufs wrote:
| 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.
| heavyset_go wrote:
| Yeah, it seems pretty half-baked at the moment. It looks
| like QML is the intended target for mobile apps on the Qt
| side.
| serial_dev wrote:
| 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.
| heavyset_go wrote:
| Last time I looked at Flet, it gave the impression that you had
| to use the wrapped Flutter widgets, making it hard to use
| widgets and packages from pub.dev in a Flet application.
| pyeri wrote:
| I feel like an old grandpa while using tkinter!
| dzonga wrote:
| out of all cross platform tools - dart / flutter is probably the
| easiest one. performant comes with all the widgets you want.
|
| web, mobile etc. react paid my rent but never again.
| brnt wrote:
| Flet doesn't seem to have a Treeview. I find that actually few
| cross platform GUI toolkits do. Qt, Swing, Wx, but the trendy
| ones?
| kerkeslager wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-06 23:00 UTC)