So true... some people seem to appreciate the their "aesthetics", but many 2022 UIs are just much worse than what we used to have with... Windows 3.1, or System 7 on Mac. They had uniform keyboard shortcuts (at least Windows, no idea for Mac which I used only very rarely), uniform window controls, applications that didn't need a 150 MB runtime... the worse, is that this is still possible today, just many people don't even bother to try doing it.

I think there's an entire generation that think that UIs should be bloated and slow and have taken web apps to be the norm. It's very sad.

Time for a new cycle of replacement, we are already seeing storage of data on the computer rather than on someone's server as a feature.

I' redoing all the UI on my eCommerce app to be "server driven" across iOS, Android, Web.

I get near parity on design on all platforms yet keep full native speed on mobile.

The main issue with old widget system is how hard is to theme them, and theming is, I think, a major driver of the use of HTML/CSS (certainly on my business customers, where they demand the UI be colorized with their corporate stuff!).

Fix that (like with SwiftUI) and suddenly using native is more doable (bussines-wise).

Combining with server-driven architecture, so far my eCommerce app with 3 dozens of screens is made with 2 files of SwiftUI (app specific, plus a one-time cost in build the boilerplate), very doable to a solo guy to code all in 3 platforms.

I wish theming would go back to being something we as end users do to our whole system, not something forced upon us by app developers (or their corporate overlords).

From their ReadMe

>> wxWidgets licence is a modified version of LGPL explicitly allowing not distributing the sources of an application using the library even in the case of static linking.

[1] https://github.com/wxWidgets/wxWidgets

it's the same garbage license

I’m truly curious, is this because it rules out distributing a statically linked binary? I may be misremembering, but I thought LGPL is completely fine for commercial apps if you’re just looking against the LGPL’d code.

LGPL stipulates that you should be able to link against your own version of the LGPL library you're integrating, that's to say a user should be able to run an app with their own version of the LGPL library if they want to.

For some app distribution channels, like with iOS apps, that can be difficult to impossible to actually implement given the control Apple has over app packaging and distribution.

Otherwise, you should be able to distribute a commercial non-LGPL app that uses an LGPL library just fine as long as you meet that stipulation.

As others have pointed out, WxWidgets ships with a modified LGPL license that makes this point moot, anyway, and makes it easier for commercial apps to comply with the modified license compared to the bare LGPL as they are free to statically link WxWidgets and distribute apps in compliance with the modified license.

Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out?

You theoretically can.

>> Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out?

You also have to offer them source code, or just ship it along with.

Doesn't the LGPL exempt linking from the "viral" nature of the GPL?

I meant source code of the library part. Correct, your app can stay closed. You still have to comply with the redistribution requirements of the LGPL code.