Ultra App Kit 1.1 Released As New Cross-Platform UI Toolkit

[tildearrow]

What?

It's dual licensed. you can use LGPL and link dynamically in proprietary software.

It has been LGPL since aqcuired by Nokia, so RTFM and please don't spread FUD.

https://www.qt.io/licensing/

As long as you don't modify the library for your personal purposes, yes.

But most companies do, and obviously they wouldn't feel like releasing the sources to their modifications (as required by LGPL), so please think a bit more.

[ssokolow]

Sorry about that. I updated the product pages in the store to include a link to the EULA. Use it for commercial products with no royalties due, ever. Basically, the only restriction is you cannot make a GUI toolkit with my GUI toolkit. (This kind of thing does happen with game engines if it is not explicitly forbidden.)

It is completely possible to make an open-source project with Ultra App Kit if the UAK libraries and headers are not distributed with your source code, so that it requires a UAK license to compile. Depending on your usage that might or might not be appealing, but it is doable.

Is this without source access (like a non-gratis version of how Sciter's free tier works?) or with source access?

[JoshKlint]

Is this without source access (like a non-gratis version of how Sciter's free tier works?) or with source access?

The main application is a project generator that lets you create a new project with all the required files ready to compile for GCC, Xcode 12.2 or later, and Visual Studio 2017. The library itself is distributed as a precompiled static library with headers, with binaries for Windows, Linux, and Mac. Source code for the library itself is not provided.

The project is ready to use with Visual Studio Code on Linux, but since a makefile is provided you could also modify it to work with many different IDEs.

[Morty]

No evil_core there is a problem with LGPL and with dynamically linking with closed source game developers and anti-cheat logic. Really static linked as long as end user and relink is technically legal with LGPL as well. Lot of GUI intended for game development if open source are MIT or BSD or something like it where they can be linked into the executable with no requirement that the end user has the rights to change them. Think about it if you could replace the graphic GUI library with a hacked version you can get up to a lot of mischief with a game.

No, that is a non issue. Since you would not use Qt for the in-game graphic in any case, so it would not touch the gaming part of the code. You use Qt for the config screens, lobbies and set up stuff, quite separate from the gaming code and anti-cheat logic.

[Morty]

As long as you don't modify the library for your personal purposes, yes.

But most companies do, and obviously they wouldn't feel like releasing the sources to their modifications (as required by LGPL), so please think a bit more.

Really, they do?

That is not my impression, to me it seems like they usually run with the pre-compiled libraries not even touching the source distribution. And from experience, most developers I have worked with they tend to try staying away from touching the toolkits and libraries used as hard as possible. And in a commercial setting that makes sense. Every hour spent working on the toolkit, is an hour of lost productivity on the application or product you are developing.

[ssokolow]

The main application is a project generator that lets you create a new project with all the required files ready to compile for GCC, Xcode 12.2 or later, and Visual Studio 2017. The library itself is distributed as a precompiled static library with headers, with binaries for Windows, Linux, and Mac. Source code for the library itself is not provided.

The project is ready to use with Visual Studio Code on Linux, but since a makefile is provided you could also modify it to work with many different IDEs.

OK, that's not exactly the most compelling option for open-source. If it's not a game, Qt's QML provides a GPU-backed retained-mode GUI and GTK is aiming for the same thing... both with full source access under the LGPL and a much bigger support base.

If it is a game, there are various options for open-source embeddable GUIs such as CEGUI and, for the immediate mode ones, the argument there is that you have more ability to ensure that the time taken to render a frame's GUI components will be predictable, allowing them to be well-suited to GUI elements visible during gameplay... and that's assuming you're not using something with a built-in retained-mode GUI system like the Godot engine.

...and for stuff that's "very" open-source, where they don't bat an eye at GPL-licensed dependencies, your current licensing model would basically force them to try the trick nVidia does with their binary drivers and hope nobody goes after them in court for not being able to win a war of attrition the way nVidia is... well, that or split their app into two separate processes communicating over IPC similar to how GPLed archival GUIs support .rar by invoking UnRAR as a subprocess.

[oiaohm]

No, that is a non issue. Since you would not use Qt for the in-game graphic in any case, so it would not touch the gaming part of the code. You use Qt for the config screens, lobbies and set up stuff, quite separate from the gaming code and anti-cheat logic.

This is wrong when you get into AAA titles. Where you find stuff like https://github.com/ocornut/imgui used, Config screens and lobbies and windows that can be put on screen during game play being the same toolkit gives a unified experience. Please note you said config screens what about game config windows. As in config windows that alter configuration you can raise by a keypress to alter audio.... while you are in the game. Yes config windows like this end up normally rendered to screen by the game engine using part of what it using for the hud. This is the problem QT LGPL does not fit this usage case. Having one toolkit for you in game config windows and one toolkit for you full screen configuration screens/lobbies normally undermines the feel due to inconsistency. Yes you see lower grade title doing this because they don't understand that its part of a good game experience to use the same GUI toolkit across all windows and this does put some license restrictions and does mean the GUI toolkit has to be anti-cheat compatible. There are ways to cheat by modifying in game popup windows.

Morty there are reasons why you are not seeing Qt and items like it in the AAA and why it not preferred. There are still tones of options like Dear Imgui that do not have a fee and tick all the boxes you need to make a good game GUI experience at AAA required consistency.

Morty its common mistake to say your GUI toolkit is not need for in-game graphics that as you game develops normally results in you have 2 GUI toolkits in use as in 1 for in game and one for out of game so breaking the experience. Please note this normally turns into 3 GUI toolkits. 1 GUI toolkit for the installer/uninstaller and 2 in the game play. Its really bad enough have 1 GUI toolkit for the installer and 1 GUI toolkit for all the game bits. Remember each extra GUI toolkit you have its another thing that your developers have to know how to use as well.

[oiaohm]

If it is a game, there are various options for open-source embeddable GUIs such as CEGUI and, for the immediate mode ones, the argument there is that you have more ability to ensure that the time taken to render a frame's GUI components will be predictable, allowing them to be well-suited to GUI elements visible during gameplay... and that's assuming you're not using something with a built-in retained-mode GUI system like the Godot engine.

This is something the Immediate Mode UI https://en.wikipedia.org/wiki/Immediate_mode_GUI the two majors that are actively maintained is Dear ImGui and Nuklear. You do have people using the Godot engine then using Dear ImGui or Nuklear to give more graphical GUI options and the appearance they want.

CEGUI last update 2016 last post 2019. There are tones more are actively under development. The license of the immediate mode GUI options is generally MIT or Zlib or Public domain. Yes game engines commonly have their own immediate mode GUI option option as well.

https://github.com/raysan5/raygui You also have cases like this where people have liked a particular game engine GUI and them proceed to make their own clone for using out side. This is that unified experience thing going the hard way. The amount of effort some game developers do so their interface is consistent at times get quite insane but the does result in those playing the game finding it better.

Something that is interesting is poorly covered this Immediate Mode UI libraries are by the wikipedia.

[Morty]

This is wrong when you get into AAA titles.
...

This is the problem QT LGPL does not fit this usage case..

That oiaohm is a red herring, it's a non issue.

When you get into AAA titles, if they decide to use Qt, going for a commercial license would be obvious. So Qt LGPL would not be an issue, none of those perceived issues would be valid.

[oiaohm]

That oiaohm is a red herring, it's a non issue.

When you get into AAA titles, if they decide to use Qt, going for a commercial license would be obvious. So Qt LGPL would not be an issue, none of those perceived issues would be valid.

Funny this got a upvote. AAA titles have written their own solutions like one I have said many times Dear Imgui this is used in Blizzard AAA titles. Reality is companies behind AAA titles it cheap to write there own solution than pay for Qt commercial license and its less restricted on functional platforms.

The companies that make AAA are quite focused on costs on one side. QT commerical and Qt LGPL are not Immediate mode GUI either so are not design for GUI output to be rendered by a game engine or some other third party either. Qt targets operating systems not to be game engine compatible.

Go back and read that post carefully what I will point it out.
Yes config windows like this end up normally rendered to screen by the game engine using part of what it using for the hud.
This was the use case in the line before I said Qt LGPL does not fit the reality here Morty neither does Qt commercial this is having the game engine render the output not the operating system. The reality is Qt is not better than Dear imgui for the game use case in fact Qt is worse particularly with how important consistency is to a good experience..