Looks cool, but makes me sad that they have to do it. This industry is so annoying sometimes.

Also, sad to see classic widgets continue to get no love. I know it's a lost cause, I'm just sentimental about it.

And their commercial offerings are very pricey indeed ($6000 a year).

I'd recommend users to switch to wxWidgets.

See my other comment: https://news.ycombinator.com/reply?id=23322197&goto=item%3Fi...

- Decades of active development - Proven concepts (same paradigm as .Net, VB and Delphi) - Supports a lot of OS/CPU.

Edit: To get started easily with tasks like cross-compiling, getting the trunk edition, and so on, use (https://wiki.lazarus.freepascal.org/fpcupdeluxe) to perform the download and installation.

Now if there were something like Lazarus, but for Rust, the HN crowds would go nuts.

If Borland had kept their indies demographic, hadn't made their half-backed attempt to Linux with Kylix, the history would most likely played in a different direction.

When you choose this wording or stuff like "someone is worried" then it's a plain FUD.

Python is supported for ~5 years (closer to 6 in practice) without any promise of an lts release. https://www.python.org/dev/peps/pep-0537/#lifespan Would you want more than that?

https://download.qt.io/archive/qt/5.15/5.15.0/single/

GTK is always GNOME first and has issues most other places or just looks ugly.

wxWidgets always looked off and had the weirdes issues.

Qt (or at least QtWidgets) was fairly solid in design and implementation. Then they kind of put that on ice and started with a second GUI framework (QML) that didn't fit together whatsoever. Now it has a split personality and the widgets part has a hard time to keep up with modern problems like high-resolution screens and and scaling (I'm writing this from KDE, so I know first hand).

Then everyone tried to re-invent the user interface paradigm and that's how we ended up in the current mess. Consistent buttons, input boxes and frameworks were replaced by flashy but fairly unusable interfaces, which of course did not work out. So now we have this weird mix of not letting go and not knowing where to go.

You could go very old school though, with something like http://www.fox-toolkit.org or https://www.lazarus-ide.org/

wxWidgets?

For audio-related software (such as Helio Workstation[0]) there is JUCE.[1]

[0] https://github.com/helio-fm/helio-workstation

[1] https://en.wikipedia.org/wiki/JUCE

    $ ./score-v3.0.0-a4-Linux.AppImage
    Illegal instruction

It is a tough learning curve but I'm starting to see the light. Depending on your application, completely self-contained GUIs don't actually need that much code - it's mostly the knowledge of how to architect them.

A hard problem is how to approach construction of Widgets and hierarchies of control elements. The traditional OO centric approach is far too much boilerplate to be practical without a huge third-party library, but the Immediate GUI approach which got talked about a lot recently is maybe a little simplistic. I think I've found a good middle ground between "immediate" and "retained".

- it is capable of storing state: storing position in scroll view, which page is currently visible, etc. - it tracks dependencies, so ideally UI building code is executed again only if something changed that would affect it's output.

The important point is that I don't allocate and re-initialize the state of all controls. It's enough if you do from scratch the layout - that gets much simpler if you don't have to code a diff against the previous state.

So I basically have a simple Widget abstraction - a draw function and a process-input function + some identification data (implemented as a union of void-ptr and int). I can then make lists of these abstract Widgets, and each list represents the set of childs of a superordinate element.

This abstraction allows me to construct hierarchies and to have unabstracted and very flexible code for the layout, while the layout and input processing code can be generic - it's a simple loop over the list, calling the callback with the abstract handle.

If there are ever performance problems you can still fluidly move more towards some retained layout state. This for sure will require more complex code, but if you just do it for complex layouts with lots of elements, I figure you get the best of both worlds.

Mouse and drag handling is a little bit tricky as well - how to keep sending events to the slider control widget for example even if the mouse is temporarily outside the widget? The important realization is that dragging needs global state. You set the mouse globally as "grabbed" and provide a callback to execute when there are more mouse events.

I don't do Macs so far, so I can't tell you about that. I have a little boilerplate for setting up a window and getting input events for X11 (Linux) and Win32/GDI. It's about 300-400 lines each.

You can opt to use GLFW3 instead to target all the big platforms with a single file that is also 300-400 lines. Mac is supported, too. I have mostly ceased to use GLFW since I prefer to code the stuff myself to have absolute control in case I need it, and to understand the issues of the platforms I have dealt with - but frankly GLFW is a very good and sleek library to get an OpenGL window and some inputs.

Getting to the web using emscripten was similar. They support an older GLFW2 API so it was a matter of maybe 30 minutes to convert my GLFW code to run on the web. They also have a HTML5 API (html5.h) which is probably better, so I expect to add another couple hundred lines later at some point for that.

Emscripten / the Web required me to port my desktop OpenGL code to OpenGL ES 3.0, which was quickly done and a very good idea to do anyway.

And after all, the OpenGL rendering backend code is not that big either if your architecture is right. Mine is currently 700 lines, and it supports solid faces, textured faces, alpha-channels, subpixel font rendering - all of course for 2D and 3D.

Last time I had to do a gui, I chose JavaFX, and it was fine. But I’m still looking for native options, even if I have to implement the ui 3 times.

Edit: to clarify, I’m looking for something beyond C/C++

It you want to explore the Rust option, here is an overview of the status of GUI toolkits in Rust: https://areweguiyet.com/

Also - while a lot more low-level - Skia. Sublime Text/Merge and Aseprite are using it.

But show an app made with it to anybody below 30 and they will call you an ancient fossil.

If something doesn't have transition and gesture nowaday, you better market it to accountants because the general public won't want it.

Everything I do on a computer, apart from the odd movie I watch, is centered around information in text form, yet literally every program except decent text environments try their best to ruin working with text. The only place where I think a non-text-based ui actually adds something is in calendar applications, yet most of the suck as well.

So I sit here alone with the marvel that is 1980s technology, thinking most things regarded as "modern" in computing are a farce.

The only new general purpose tool I can stand is VSCode, where my o my critique is that it isn't emacs (and that multiple cursors are a decent but not a great replacement for macros)

http://fox-toolkit.org/screenshots/iims3.png

edit Too late I see skriticos2 already mentioned FOX.

You can use Gtk to make executables on Windows and MacOS, but it's not comfortable and the resulting guis are ugly. They do not take advantage of the full provisions of the platform. Gtk is less cross platform, and more a foundational Gnome library that someone has ported to Windows and MacOS. No support for two major operating systems.

Qt I can't speak to.

WxWidgets seems to be a little .. dated. The screenshots on their website look like programs that were acceptable for a technical user 15 years ago. Has it moved on from that? Dunno. No support for two major operating systems.

> Qt is available under the GNU Lesser General Public License version 3.

- Installation of Qt binaries will require a Qt Account

- Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only

---

Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.

vcpkg install qt5

With vcpkg and other alteratives in the picture, it's far less hassle to use that than mess around with the slow and flaky installer tool.

How is this compatible wit the LGPL? Can't I host a compiled copy of Qt and let the world install it?

Of course you can do that, as long as you respect the LGPL. That's what pretty much every Linux distribution is doing. It's just that the old Qt offline installer by the QtCompany is no longer available.

Qt hasn't for a while distributed binaries for the open source release, but there were publicly downloadable binaries for the trial version of the commercial release which is what has now gone. But as you say, nothing stops _others_ from distributing binaries for the open source release.

Companies can do this for open source projects. They require you to sign a contributor agreement handing over over copyright or require you license the code to them under the MIT. For the most part, differs based on region and IANAL.

Edit: corrected in () that you can comply with the LGPL with static binaries with providing an object file to the user to relink with.

How come? The LGPL allows people to distribute statically compiled binaries that use Qt, you do not need an exception for that.

Hmmm... you can as long as you provide an object. Learned something new today. I do remember Mike discussing that on Coder Radio that would be an issue in the security industry. I assuming there were some aerospace libraries that are NDAed/restricted by national security laws.

https://stackoverflow.com/questions/10130143/gpl-lgpl-and-st...

http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

Is this possible on iOS? Not familiar with iOS dev, but I assume Apple may have some TOS problems with that.

See the note here at the end: https://github.com/freedesktop/gstreamer/blob/master/README....

> But last week, the company suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice.

[0] https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.

Or, in more words as Qt pusts it:

> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.

It has nothing to do whether mirrors do exist or not, when there will be nothing to mirror.

Distributions ship binaries with OS anyways. You won't have to build it yourself.

Project like VLC or QGIS have releases not only for Linux, but for Windows and Mac too.

But I think that adding friction to the "download binaries from some site" is doing nothing more than alienating Windows developers. Qt just must add something like "Sign in with Google/Facebook with one click" because this audience cares about convenience.

Isn't Red Hat doing the same thing, even worse I think they were obfuscating some stuff just to make things harder for competition.