[HN Gopher] Kivy - a cross platform Python UI framework
___________________________________________________________________
Kivy - a cross platform Python UI framework
Author : peanball
Score : 194 points
Date : 2024-07-06 16:27 UTC (1 days 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.
| KaiserPro wrote:
| Kivy is old, so its improved more recently, but animation
| in HTML/JS is not power efficient.
|
| Everything is GL accelerated, so the UI is snappy and fast.
| 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.
| KaiserPro wrote:
| > this is most European website
|
| 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.
| 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.
| setopt wrote:
| It's not the researcher's fault if the libraries they use
| make breaking changes after a month; proof-of-concept
| code published with a paper is supposed to be static, and
| there's often no incentive for the researcher to maintain
| it after publication.
|
| 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.
| 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.
| forrestthewoods wrote:
| > 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.
| bomewish wrote:
| Are you just describing something close to Nix?? In any
| case, Nix solves a lot of these problems.
| forrestthewoods wrote:
| 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.
| xyzsparetimexyz wrote:
| Nix != NixOS. It runs on WSL: https://github.com/nix-
| community/NixOS-WSL
| forrestthewoods wrote:
| Less than zero interest in WSL.
|
| Nix fans are becoming as obnoxious as Rust fans. And I
| say that as an times annoying Rust fan.
| skeledrew wrote:
| Actually conda creates hardlinks for the packages that it
| manages. Found this out a few weeks ago when I tried
| migrating my envs to another system with an identical
| hierarchy and ended up with a broken mess.
| 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.
| skeledrew wrote:
| I install most tooling, including Jupyter, using pipx.
| The only thing I then need to install in the project
| venvs is ipykernel (which I add as a dev dep), and then
| create a kernel config that allows Jupyter to be run
| using that venv.
| 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.
| kerkeslager wrote:
| 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_ ).
| 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.
| bartekpacia wrote:
| Sounds like AccessKit [0] to me
|
| [0]: https://github.com/AccessKit/accesskit
| bmitc wrote:
| Thanks. I'll take a look. But it being in Rust makes me a
| bit hesitant. A lot of these projects in Rust seem to
| fizzle out as soon as people get bored with them once they
| become hard.
|
| Do you know of anything major that's using it?
| cglong wrote:
| Not quite what you're asking for, but Microsoft (my employer)
| has a free tool for checking web and Windows apps for
| accessibility best practices:
| https://accessibilityinsights.io/
| hsbauauvhabzb wrote:
| HTML
| 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
| ...)
| bitwize wrote:
| On Mac, the only thing that looks and feels native is the
| actual native Objective-C or Swift framework.
|
| 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.
| winrid wrote:
| In my case the users were just really happy we solved the
| problem, I don't think they would care if it ran on
| minecraft redstone.
| 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.
| mardifoufs wrote:
| 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?
| m_kos wrote:
| Thanks for sharing your experience and links! Based on plyer's
| GH, it looks like you could use it to develop an iOS and
| Android app. If it supported more APIs (like Health Kit,
| accessibility), I would try it in a heartbeat.
|
| https://github.com/kivy/plyer
| 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.
| skeledrew wrote:
| If something isn't supported you can open an issue, or add
| that support yourself. The latter is relatively easy to do
| nowadays.
| serial_dev wrote:
| That seems to be the case even today:
| https://flet.dev/roadmap.
|
| As I see, you can use pure python packages, but not Flutter
| packages or Python packages with some other languages in the
| mix.
| BaculumMeumEst wrote:
| 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?
| Operyl wrote:
| Why do people write frameworks on top of programming
| languages that other developers wrote?
|
| 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.
| cle wrote:
| > What are we gaining here that is worth such an enormous
| risk?
|
| 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.
| serial_dev wrote:
| While the risks you mentioned are indeed valid risks, it
| doesn't automatically mean that these risks (however small or
| huge they be) outweigh the benefits the Flet project offers.
|
| 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.
| BiteCode_dev wrote:
| What do you mean by "Flutter developer trying to pivot to real
| native development" ?
| insane_dreamer wrote:
| Interesting. Looking for something like this to use instead of
| Flask, which is great on the server side but need something
| that's easy to work with on the client side that provides a
| feature complete and nice looking set on controls for the
| client side.
| pyeri wrote:
| I feel like an old grandpa while using tkinter!
| analog31 wrote:
| I still use tkinter for apps that I make for my own use. Those
| are often for lab automation, where a primitive GUI lets me
| avoid needing 3 hands while running an experiment, and the
| support for live graphs is extremely useful.
|
| 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.
| pyeri wrote:
| I think it's possible to use tkinter to develop even modern
| apps which don't look primitive, there are many open source
| projects which have done that including the IDLE editor
| itself, a part of core python project. The only issue is that
| it sometimes becomes excruciatingly difficult or painful to
| even perform some very little non-trivial things (like
| customizing a data-grid with a different style or having
| multiple tabbed pages) which are quite a simple task in other
| toolkits as they're already available in the form of a widget
| or component.
|
| 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.
|
| [1]: https://www.freepascal.org/
| 7thaccount wrote:
| I think you mean freepascal + Lazarus IDE/RAD right? I
| think the Lazarus tool makes GUIs somewhat easy to build.
| JodieBenitez wrote:
| ttkbootstrap made me interested in tkinter again:
| https://ttkbootstrap.readthedocs.io/en/latest/
| 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?
| anonzzzies wrote:
| Maybe Flet doesn't but there are free view packages for
| Flutter (which was what GP mentioned).
| 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.
| bionhoward wrote:
| Every time I see a claim some thing is "the thing" I wonder about
| how many other things do similar things
| OJFord wrote:
| Docs > Getting started's only code is in a screenshot? (That
| doesn't render properly, legibly, at least for me right now, on
| mobile?)
| dang wrote:
| Related:
|
| _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)
| prophittcorey wrote:
| Kivy led to one of my first open source contributions in 2014. I
| submitted Kivy file support to Vim. It was done via patch diffs
| over email with Bram Moolenaar. It's still in Vim today[1].
|
| RIP Bram.
|
| [1]:
| https://github.com/vim/vim/blob/master/runtime/syntax/kivy.v...
| frakkingcylons wrote:
| Nice, that's pretty sweet. Also RIP Bram, great human being.
| kumarvvr wrote:
| All these types of frameworks, ones that have code to make their
| own UI are fine, but what I really want is to have a declarative
| UI, like HTML or XAML, bound with some user interaction event
| engine and access to the underlying OS.
|
| 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.
| JodieBenitez wrote:
| Pywebview + Pyinstaller gives you just that.
|
| https://pywebview.flowrl.com https://pyinstaller.org/en/stable/
| tzury wrote:
| It's 2024.
|
| None of the screenshots under the gallery are compelling or even
| acceptable these days.
|
| https://kivy.org/gallery.html
|
| Electron thus far seems to be the king of "desktop" ui.
| KaiserPro wrote:
| > 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.
| mikrotikker wrote:
| Please anything but electron dear god
| openrisk wrote:
| For Kivy to stop being a niche UI framework with marginal
| adoption it must somehow tap into the central role of Python in
| the broader data science / machine learning universe.
|
| 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.
| xyproto wrote:
| Katrain uses Kivy and is problematic to package and upgrade
| because of it, on rolling release distros. When installing it
| with pip, it partially works.
|
| From a packaging point of view Kivy is not great.
| 7thaccount wrote:
| All of Python is pretty terrible from a packaging perspective.
| holistio wrote:
| Am I the only one who read Kyiv?
| ChrisChou wrote:
| I have been following the progress of this project for the past
| two years, but unfortunately the community support does not seem
| to be ready to take this project anywhere. The most basic app
| store in-app purchase support is directly rejected. If an
| application framework cannot quickly help people get started, how
| can it get people's support?
| fefferkorn wrote:
| i like nicegui, but its more a web ui framework thing than a
| fully fledged desktop ui.
___________________________________________________________________
(page generated 2024-07-07 23:02 UTC)