Elements C++ GUI Library | Hacker News Reader

Elements C++ GUI Library

github.com

128 pointsturrini45 comments

Firstly, this looks fantastic. And the GUI not taking over the main loop is a wonderful feature. This is something that has really irritated me using most other GUI libraries (including Qt).

> The GUI should be declared in C++ code.

While I love the declarative aspect of the above, would the authors consider using a different DDL for layouts rather than C++?

The reason I ask is: this now enables creation of wrappers around this library for other languages like Golang and Python.

Also, having the layouts described as plain data rather than C++ code would allow not having to compile for minor UI/layout changes. Which will in turn permit faster prototyping during UI development.

First time loading any of the examples it takes a noticeable time but it creates some cache files e.g. "e33b398b592a74de7cce1c9035ee8082-le64.cache-7" which seem binary. Subsequent loads are fast.

Agreed, C++ for declarative-anything is a bad idea and will make compile times suffer a lot.

Looks cool! I wonder how this compares to Dear Imgui in terms of features. (I understand this may not be an immediate mode toolkit, so not really discussing that side of things)

Would the usual competitor to this be JUCE?

While I am a big fan of Dear Imgui it's very difficult to skin it and for a VST plugin you expect this feature.

I don't think so. JUCE includes an audio/dsp engine. This is only for UI

The DSP module in JUCE isn't production quality, and the audio I/O integration in RtAudio is good enough for even professional use cases.

JUCE is really painful to use if you want to integrate it into anything modern. It's old, it's slow, and you really can't make it better. I really can't express how much distaste I have for JUCE after shipping multiple products built on it - it solves _one_ hard problem (wrapping AU, AAX, and VST3), other than that it is dog slow and can't be improved because the core devs don't accept outside contribution for no reason except their own hubris.

Any cross platform UI in C++ that isn't JUCE or Qt is highly welcome. Especially one that allows me to pull in external dependencies and use modern build systems, test frameworks, CI/CD, and other tooling.

I have been playing with Dear Imgui lately, and while its super easy to get up and running, I realized it doesn't have support for zoom (cmd +) and accessibility (unless I missed something).

It seems like those features are out of scope for the library - which is fair, one has to draw the line somewhere, and there are enough success stories with the project that it may not matter to a lot of the people. The author has mentioned in various places it's mostly for internal tools or game dev, which makes sense.

I am glad more toolkits are coming up (both for C/++ and Go, the languages I am interested in writing desktop apps with), but I am a bit surprised Qt seems by _far_ most mature compared to a lot of newer tools, not counting wxWidgets or glade/gtk3.

Very few C++ UI frameworks deal with accessibility or platform UX standards like zoom (ctrl +). You have to use platform/native APIs directly, or frameworks that seek to model them (which usually are not native).

It's not unsurprising to me that Qt is the most mature. It's the oldest, most widely used, and probably the most well financed...

Also, I can really see the appeal of electron now (from a development standpoint).

It really is Qt vs Electron if you want to ship a product that makes money - something I am paying for is expected to have a lot of these "features".

Yeah, I guess the key is the last part of your last sentence, heh

> the most well financed..

I suggest looking at wxWidgets. Fully cross platform, no commercial/paid version, all open source, without any of the org issues facing QT, and it's... a classic GUI.

I'm interested in seeing if Elements can integrate. WxWidgets has the typical amount of code (more than a little, but not much more) to create one's GUI. There's significantly more than just a GUI, BTW.

I also tried Dear Imgui, but had to back out due to the constant rendering requirement of Imgui, because my applications are already hi-compute and a persistent GUI is required when you're already pushing the CPU without any GUI.

What's wrong with Qt? I really like it.

Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under. There's also the issue where if you get a commercial Qt license it's much more difficult to contribute to Qt under GPL or LGPL. And of course the license is tremendously expensive unless you're making serious money with the application, so prohibitive to smaller companies. I love Qt but I would never feel comfortable using it in a commercial project. There was also this bullshit earlier this year where they tried to pressure KDE into worse terms https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

> Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under.

this part has always been clear:

"Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreements stay valid in case of a buy-out, a merger or bankruptcy."

https://kde.org/community/whatiskde/kdefreeqtfoundation.php

Yep, but a hostile entity that owns Qt can do a lot of damage to Qt by publishing on the last permitted day, and denying community contributions and destroying community governance. I can definitely imagine a hostile corporation like Oracle doing so (and they have form).

Qt is still available as GPL. Even if the Qt company goes under today and nobody picks up development, it's stil a great package for many years to come.

I agree behavior lately is not great, and a Qt company in trouble won't be good, but I think the community will pick up quite a bit if it comes to that.

I also think many misunderstand or misrepresent the implications of a GPL only Qt (for closed source applications). It's a matter of linking correctly: https://news.ycombinator.com/item?id=23321448

Right, of course it is, but if the Qt company goes under the highest risk is that its assets get purchased by a hostile entity, which releases everything with a year's delay and doesn't allow community governance/contributions. Imagine Qt owned by Oracle and you'll understand my concern. Of course if that happens KDE and the other current Qt users will likely fork it, but someone like Oracle can do a shitton of damage to the community in the process by threatening litigation.

The issue with the commercial licensing is that if you are a commercial licensee you are contractually prevented from contributing to Qt in some ways. See https://www.qt.io/terms-conditions/ and search for "Prohibited combination". If you are able to comply with the GPL or LGPL components without becoming a licensee, this is better in every way (you get to contribute, you have much more legal safety if the company gets acquired by a hostile entity, you don't have to worry about what happens when your license expires, and of course you save money). So those license terms are actively preventing the Qt company from getting revenue, because you get a worse deal in most ways if you pay them than if you don't. This is why I'm uncomfortable with Qt in non-GPL/LGPL commercial projects. You get trapped and you can't relicense your project to GPL afterwards even if you want to.

I really dont get why people still throw FUD with this argument. It's been what, 25 years already since this argument lead to the KDE Free Qt agreement?

At this point the biggest concern for the Trolls (or whoever owns Qt nowadays now) should be that the FUD against GPL is starting to slowly evaporate, so even big companies are starting to use GPLd Qt rather than pay licenses. By the time they go Oracle there will not be much they can do.

Have you tried the latest version of JUCE? I think it supports cmake now.

I've actually been using JUCE with CMake for ages using this project:

https://github.com/McMartin/FRUT

It's meant to convert Projucer to CMake files, but we just create them ourselves. The CMakeLists files come out a bit wonky, but it works.

I did briefly. The CMake integration is... quite strange. It kind of has to be because of how strange the compilation model is for a JUCE project, where all your includes depend on having the same set of preprocessor definitions.

I switched to Juce 6 preview branch last week. It's not without problems but getting rid of the Projucer is amazing. Now you can have a clean CMake setup and you are not stuck with Xcode on the mac.

JUCE is a reasonable comparison, as Elements specifies it wants to be a UI for plug-ins like VST & AU, and JUCE is dominant in the audio plug-in space.

But you're right, JUCE is more than just a UI.

What are the technical details behind how it avoids creating an event loop? Is it just creating a UI thread that is doing the event loop work in the background?

If there is no event loop I assume it has to be callbacks from the OS?

Isn't there still an event loop internally though even with callbacks?

I guess there need to be one somewhere unless you do hardware interrupts.

It seems to have an event loop though:

   void app::run()
   {
      MSG messages;
      while (_running && GetMessage(&messages, nullptr, 0, 0) > 0)
      {
         TranslateMessage(&messages);
         DispatchMessage(&messages);
      }
   }

NOTE: That is the classic Win32 event loop.

This looks really great--fully modern C++ coded by the best of the best! If it is like his other work, it will be a joy to use.

Ironically, the last update is the removal of Boost dependency :)

I’m curious, why is that ironic? Removing Boost dependencies in favor of modern STL is a common and healthy chore.

Of course. Just the parent mentioned his other prominent projects - which are several Boost libraries actually.

Well, I am not sure I call huge compile times a joy to use...

Abusing metaprogramming is always a bad idea.

> Well, I am not sure I call huge compile times a joy to use...

I just compiled this on windows and a full build after cloning the repo took about a minute.

How does this do on the "integration" part of GUI? Like is it easy to spin a "native" file picker on Windows/macOS?

(Sure there are native APIs for that, but bridging the gap is one of the point of a cross-platform GUI framework, isn't it?)

Nice with effort being put into fesktop GUIs. It is really an area that degraded alot I feel ... with many framewotks being just too complex and interdependent on stuff so you can't keep the build quite clean.

Is all rendering done using Cairo?

I was wondering if it uses native controls on each platfrom.

No one does that anymore because the differences between platforms are too large and there is no single platform native controls anyway.

I wonder why this lesson we learnt from desktop GUI development doesn't apply to mobile apps. Seems like the preferred approach there is to use native controls.

The APIs are better.

Come on, what platform has recording studio knobs and sliders as its native controls?

Windows has sliders. I have no idea about MacOS.

Windows does not have those exact sliders that you see in the screenshot. I don't think the available styling options can make them look like that:

https://docs.microsoft.com/en-us/windows/win32/controls/trac...

It's probable doable with custom drawing, but that heavily ties the code to the Windows protocol for custom drawing of controls.

Reply on news.ycombinator.com