Live data from Hacker News

BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

github.com

21–30 of 32 posts

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#22

It's a shame that for a GUI toolkit, there are no screenshots, either on Github or the official project website. It's very difficult to evaluate this based on descriptions alone.

They do have screenshots on the first page of the docs though, so that's at least something. https://toga.readthedocs.io/en/stable/

Unfortunately they remind me of AWT.

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#23
post #18

Earlier quoted context omitted.

GUI visual editors fail when they ignore problems that Borland Delphi and C++ Builder solved brilliantly well over 20 years ago creating an incredibly quick and productive workflow, and yes, they can become an absolute mess because of this. I can only dream of the day Lazarus (FOSS reimplementation of Delphi) will work with other languages beside Object Pascal.

Which problems are those? One problem I usually have with GUI builders is that they generate huge and messy data files for the layout which can't be meaningfully diffed. Visual Basic is even worse because the form files are binary blobs. Lazarus seems to use fairly concise and readable plain-text files for its forms, although there's also some sort of binary resource files.

You'll have the same issue even with hand written code? I'd say the solution is that we need semantic diffing to show GUI changes.

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#24
I like BeeWare Toga a lot, but I'm having a hard time convincing myself to use it for anything serious. Not because of any problem with the project itself, just because I've realized that it's probably always going to be a niche offering. A few years back I spent a while looking at various GUI toolkit options out there, and ultimately came to the conclusion that cross-platform native UI toolkits are rapidly becoming an anachronism, and I should probably just bite the bullet and learn how to use Electron.

25 years ago, during cross-platform toolkits' heyday, it was a different world. People expected more UI consistency because they spent virtually all their time interacting with native applications. The Web did exist, but it was still mostly just a hypermedia viewer plus a few ecommerce sites. XMLHttpRequest was under development at Microsoft but hadn't made it into any publicly available Web browsers. The initial public releases of GMail and Google Maps, arguably the first widely-used modern Web applications, were still 5+ years away.

Fast forward to now, and everyone's completely accustomed to spending most their time interacting with mobile and Web applications that do heavy custom styling and have very little visual consistency with each other, let alone the host operating system. It turns out that we're mostly fine with it. It's not necessarily that there aren't usability problems; it's just that it turns out that inconsistent control styling is nowhere near as much of a problem as poor layout and flow.

So I think that the "it's good for users" argument for native GUI toolkits has largely fallen by the wayside. They still attract me, though. But for a different reason: Electron & friends have poor developer experience. You have to fuss with at least three languages for UI layout, styling, and control, and quite possibly at least one more if doing everything in JavaScript is not your cup of tea. And, frankly, HTML+CSS is a PITA for layout compared to many native GUI toolkits, and wrapping one's head around modern JavaScript frontend frameworks is a much bigger task grokking APIs like GTK+, Cocoa, and WinForms.

I acknowledge that Electron's easy for Web frontend developers, since it introduces very few new concepts, but for the rest of us I think that there might still be value in a cross-platform GUI toolkit that we can all use from our favorite programming language. But I'm starting to think that what it should really look like is something that's fundamentally similar to an Electron-style "we're just going to give you a canvas you can draw in and some tools for drawing in it" approach, only without all the additional technical cruft and complexity that comes with needing to support - and work through - modern Web standards.

In some ways I like what Flutter's trying to do. But it's tied to a specific programming language that I don't already know and don't feel like learning. And it's treating accessibility as an afterthought on at least some platforms, where I think that nowadays it's a non-negotiable that needs to be baked in from the very beginning.

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#26
post #9

This is the most powerful combo together with PEX to distribute Python specific dependency free apps in my testing. (As long as all the widgets you need are supported)

What's PEX, how do you use it ?

https://pex.readthedocs.io/en/latest/ Python project single file distribution tool.

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#27

I like BeeWare Toga a lot, but I'm having a hard time convincing myself to use it for anything serious. Not because of any problem with the project itself, just because I've realized that it's probably always going to be a niche offering. A few years back I spent a while looking at various GUI toolkit options out there, and ultimately came to the conclusion that cross-platform native UI toolkits are rapidly becoming…

I second the point that Electron is great for web devs who need to make a desktop app. But for desktop app first developers I find it's really unsatisfying. The landscape today is quite interesting, between qt and avalonia and electron, among others.

One huge thing that web gets right is that users of the incremental app do not have to install anything. But the consent banners and enshittification of the web experience really eats away at that advantage.

I also very much agree that native look and feel is not as important as it sounds. I'm wondering if there is some obvious way hidden in plain sight to have end user applications on the desktop without incremental installations. Steam is almost there, getting a new game sometimes doesn't feel like a new installation even when it is.

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#28

Earlier quoted context omitted.

What's PEX, how do you use it ?

https://pex.readthedocs.io/en/latest/ Python project single file distribution tool.

Almost sounds too good to be true, with the popularity of dockercontainers and the like id expect this to be much more widely used.

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#29
post #27

I like BeeWare Toga a lot, but I'm having a hard time convincing myself to use it for anything serious. Not because of any problem with the project itself, just because I've realized that it's probably always going to be a niche offering. A few years back I spent a while looking at various GUI toolkit options out there, and ultimately came to the conclusion that cross-platform native UI toolkits are rapidly becoming…

I second the point that Electron is great for web devs who need to make a desktop app. But for desktop app first developers I find it's really unsatisfying. The landscape today is quite interesting, between qt and avalonia and electron, among others. One huge thing that web gets right is that users of the incremental app do not have to install anything. But the consent banners and enshittification of the web experien…

[deleted]

Re: BeeWare Toga v0.4.0 – A Python native, OS native GUI toolkit

#30
Holy hell, this thing gets accessibility right.

This is probably the first niche GUI toolkit I've seen on HN that actually does this well. I tried with VO on Mac OS and it just works, no issues to be reported. Most other frameworks of this size have absolutely no accessibility at all. This is why using the platform is a good idea.

Post reply on HN