Graphical library for Raspberry in C / C ++

[luiHS]

 
Hi
I need to develop an application in C / C ++ with a graphical environment for Raspberry, something similar to a video game (although it is not a video game). I have to handle videos with audio, images, texts with artistic fonts, etc.

I used QT / QTCreator years ago, but I think it is currently a commercial product, with some very limited free version, so then I prefer not to use it. Searching for Google, I find SFML, GTK+ and WxWidgets, I think that all three could be installed and used on CodeBlocks.

And for now I haven't found anything else that can be used with C / C ++.
Any suggestions or advice on free environments for graphical development with Raspberry, using C or C ++?

Regards

[Nominal Animal]

Qt is dual-licensed.  Just choose community edition at the site, so you get the LGPL/GPL-licensed stuff.  Or use the distribution-provided development packages.  AFAIK, all of the commonly used Qt5 modules are dual-licensed, including Qt Creator, network (built-in browser support) and multimedia; see e.g. here.

Qt5 is object-oriented, so you'll want to use either C++ or something like Python3 for the UI.

GTK+ is LGPL-licensed, and written in C.

Both Qt and GTK+ are extensively used in Linux distributions: Qt in KDE, and GTK+ for most other desktop environments.  Some, like XFCE and LXDE, incorporate support for both.

There is also Qt Embedded, so you can run Qt applications under EGL (using the OpenGL drivers provided for Raspberry Pi) without X11, as a full-screen application without any desktop environment at all.  However, I do believe you'd need to compile the support libraries yourself from the (GPL/LGPL) sources: not that big of a deal, but you'd need to compile the libraries first, then test some of the examples to verify it works.

Assuming the application is intended to be a fullscreen one, without any desktop environment at all, only this one application running in the user interface, I'd definitely use Qt 5 Embedded.

I personally like to construct the Qt UI in Python3 instead of C++, because that way the end users can modify/update the UI themselves.  However, for a full-screen single-application case, I don't think it is as important, so in this particular case, I'd recommend C++ and Qt5 Embedded on EGL (OpenGL ES).

[luiHS]

Thanks, I think I will try QT again, but I will also try GTK + as an alternative.

The problem is that the product I need to design will be commercial, so a free license, like QT's, requires that I give my development sources so that are freely accessible to anyone, and I can't do that.

Do you know anything about SFML and WxWigdets?

[Nominal Animal]

The problem is that the product I need to design will be commercial, so a free license, like QT's, requires that I give my development sources so that are freely accessible to anyone, and I can't do that.

No.  You can create a closed-source proprietary binary that links to LGPL libraries at run time.  See e.g. here.  You only need to provide the sources to those libraries (and only if you distribute them along with your program), not your own application.
See here for a summary of the Qt 5 modules and their licensing.

In particular, you do not need to provide sources to your application that only links at run time to the LGPL libraries.  (Run time dynamic linking is the default, too.)
That is the key difference between GPL and LGPL: LGPL expressly clarifies that linking to a LGPL-licensed library does not create a derivative in the copyright law sense, and does not extend the LGPL license to the application linking to such a library.

Do you know anything about SFML and WxWigdets?

Only enough to say I find Qt and GTK+ much more powerful for development on Linux.


In practice, you should consider building your application so that it runs as a dedicated user account (because it sounds like a full-screen appliance of some sort).  Depending on how you intend to distribute it –– as a package, or as a dedicated distribution on a provided 'Pi ––, you only need to provide sources of the open source packages (including the Qt libraries) used to build the environment; just make sure your binaries are dynamically linked (do not use -static compiler option!) to LGPL or similarly licensed libraries.

Linking to the standard C and C++ libraries does not create a derivative of those, nor does using Linux syscalls.

If you provide it as a package, compile your application using -Wl,-rpath,'$ORIGIN/../lib' as described in man 8 ld-linux, so that if your application is stored at /usr/lib/yourapp/bin/executable, the default location for dynamic libraries is /usr/lib/yourapp/lib/ (or, to be precise, ../lib/ relative to the location of the binary).  This way you can provide the specific versions of the Qt libraries (and whatever other libraries your application requires) and C++ runtime there, and use the system default standard C library.  This yields a very portable way of creating proprietary binaries that work on many Linux distributions.

[SiliconWizard]

C or C++? You'll need to make a choice. There's nothing like C/C++, even though that keeps being mentioned everywhere. Oh well, that's probably never going to sink in.

So depending on the language, you'll have access to different libraries. QT is C++ of course, and using it from C, although probably possible with the right interface, would probably make no sense, and would be a lot of extra work. So with QT, of course, you'll have to use C++

Now QT embedded was mentioned not long ago, and AFAIK, it now requires a commercial license. So QT embedded is out, unless you're ready to get a license.

GTK is indeed another option. Contrary to QT, it can be used both from C and C++, there's official bindings for C++ (gtkmm).

In both cases, you mentioned playing videos, and I don't think there is any video support in QT, but I may be mistaken as I haven't used it in ages. In which case you'd have to use yet another third-party library. For GTK, I think a video widget has been introduced in GTK4, so that would probably be an easy path. Graphics are done using Cairo on GTK - you can take a look. Cairo allows pretty antialised graphics and font rendering.

In any case, I suppose you'll be using Linux on the RPi?

One option, from your description, would also be to use some sort of "game engine". There are quite a few out there, and many will get you game-like UIs pretty easily. You could consider Allegro, OGRE...

[PlainName]

The problem is that the product I need to design will be commercial, so a free license

... would be inappropriate?

[Karel]

Assuming you are using Raspbian for the OS, you only need to execute the following commands in order to
be able to compile your Qt C++ project:

Code: [Select]

sudo apt-get update
sudo apt-get install g++ make git qtbase5-dev-tools qtbase5-dev qt5-default

Now, in your Qt project directory (the location of the source of your program) simply run:

Code: [Select]

qmake
make

That's all.

In other words, compiling a Qt program on a Raspberry Pi is no different than on a traditional pc with Debian or Ubuntu.

[DiTBho]

OT:

Qt5 Embedded on EGL (OpenGL ES).

EGL is a good point for Wayland, unfortunately it seems that only a few chips have EGL support.
The RPI-v4 is on the list, but speaking of video cards ... it appears that only Radeon cards have it.

Probably the RPI is a good choice from this point of view, I mean for embedded stuff 

[Karel]

You don't need Qt for embedded, the normal Qt5 runs fine on an RPI4.
It should run fine on an RPI3 as well but I haven't tested.
No need to make things more complicated.

[Nominal Animal]

If we are as specific as possible, then there is no Qt Embedded in Qt 5, since it is replaced by QPA, Qt Platform Abstraction plugins.  These plugins include LGPL-licensed qeglfs (for OpenGL ES) and qlinuxfb (for raw framebuffer on Linux), which are commonly called "Qt for embedded Linux".

The difference to "standard" Qt libraries is that if you are running in Windows, you'll use the qdirect2d or qwindows or qwinrt (Universal Windows Platform support) plugins; qandroid in Android; qxcb or qwayland in Linux, and so on.  You only need a set of Qt libraries that enable the QPA plugin you need; thus far, I've compiled my own, but I haven't checked if the Raspbian ("Raspberry Pi OS") ones have qeglfs enabled (the qeglfs should use the accelerated OpenGL ES drivers on the Pi variants and other SBCs).

Now QT embedded was mentioned not long ago, and AFAIK, it now requires a commercial license. So QT embedded is out, unless you're ready to get a license.

No, Qt for embedded Linux is still licensed under LGPL.  It's the Qt for Device Creation that is commercial, and you don't need that.

Qt for embedded Linux is nothing but a configure time option when compiling the Qt libraries –– choosing the proper QPA plugin to use––, after all.

The QPA plugins are part of the qt/qtbase.git repository, which is licensed under several different licenses, including LGPLv3.  See src/plugins/platforms/ for the QPA plugins included in Qt.  You may even find the Qt libraries precompiled for various SBCs like 'Pis, with the appropriate QPA plugins already enabled, so you don't have to recompile anything.

In both cases, you mentioned playing videos, and I don't think there is any video support in QT, but I may be mistaken as I haven't used it in ages.

You are indeed mistaken.  Qt Multimedia widgets module does contain a video player; see the BSD 3-clause -licensed example here.

Both Qt Multimedia and Qt Multimedia widget modules are licensed under various licenses, including LGPL: see the sources.

It seems to me you've read a bit too much Qt PR, since they obviously hope that developers buy the commercial licenses, even though they're rarely necessary.

[SiliconWizard]

Now QT embedded was mentioned not long ago, and AFAIK, it now requires a commercial license. So QT embedded is out, unless you're ready to get a license.

No, Qt for embedded Linux is still licensed under LGPL.  It's the Qt for Device Creation that is commercial, and you don't need that.

I based my point on this: https://doc.qt.io/QtForMCUs/
To be fair, it's strictly about Qt for MCUs - as this is what we discussed in another thread - and not "Qt Embedded" per se, so I got confused here. They seem pretty clear that you need a commercial license for this. But this is not needed for a RPi anyway, so you're right. You can use a standard Qt on a Linux distribution for the RPi anyway? No need to go "embedded" whatsoever.

That said, I've always found Qt licensing to be something pretty obscure, and I don't doubt they maintain this impression on purpose.

I would favor GTK myself when it comes to licensing. Also for technical reasons, as I'm a lot more familiar with it, and as Cairo allows nice graphics with little effort IMO. Also for the fact a wider range of languages are usable AFAIK. But that's just me. As I said, some game engine could be a better option for the OP - we don't know much about his project.

[Nominal Animal]

You can use a standard Qt on a Linux distribution for the RPi anyway? No need to go "embedded" whatsoever.

Right.  When talking about Qt 5 and later, the "embedded" just refers to a different plugin/backend (than Wayland/X11/etc.), that works directly on the framebuffer or display device, without any X server or similar support.

For the application developer, it is the exact same libraries.

As I said, some game engine could be a better option for the OP - we don't know much about his project.

True, that's why I qualified mine with "looks like an appliance".  I was assuming some sort of an interactive kiosk system.

SDL would be another possibility.  With SDL 1.2, one would have to link dynamically (LGPL). SDL 2 has a more permissive license, but doesn't have as many backends (only X11, Wayland, and raw framebuffer, AFAIK, on Linux).

[nctnico]

Thanks, I think I will try QT again, but I will also try GTK + as an alternative.

Do you know anything about SFML and WxWigdets?

If you don't take the Qt route then go for WxWidgets. I have been using wxwidgets for a long time (>10 years) for many projects. The beauty is that it is pretty straightforward to use and it abstracts a lot of OS specific stuff. For some projects I compile the embedded Linux (ARM) version from the same source as a Windows application to run on a PC. I do development under Linux.

I've worked on GTK+ software as well but it is more low-level compared to Qt and WxWidgets and AFAIK GTK always uses its own widget set so you don't get a native look & feel if you use something else. IMHO software should adhere to the 'theme' the user has selected and not force something onto the user.

The main problem I see with Qt is that it's license changes from commercial to non-commercial every few years. That is not something you can build a business on so I went for WxWidgets.

Another option could be to use the Unreal engine. This supports cross compilation for Arm64 but AFAIK it only really supports Vulkan as a GPU backend. A couple of years ago I have managed to get the Android version to compile for Linux so it can use OpenGL-ES but the demo games didn't run so I never pursued it further.

A quick google came up with this tutorial to get Unreal running on a Rpi4:
https://www.raspberrypi.org/forums/viewtopic.php?t=293305

[luiHS]

 
Thanks for the answers.
Another issue is which IDE to use, if possible one with a graphical assistant for the forms, I think they are called RAD (rapid application development).

For Qt, I am clear that it would be the Qt Creator.
Other IDEs that I know of are CodeBlocks, Geany, Visual Studio, Codelite, Eclipse.

I'm interested in trying GTK and WxWidgets.
For WxWidgets I think CodeBlocks can be used with the wxSmith plugin.
For GTK I have read about Glade and Anjuta.

Another possibility, as mentioned, is to use an engine to design games, although in my case, as I said, it is not a video game. I only need to play videos or visualize images, and superimposed on these images put some variable data (scores and others, with an artistic font), I also need to create a configuration menu with various data.

[nctnico]

Creating forms in a tool may seem handy but in reality you will want to scale the controls to cater for various screen sizes which in turn means that you have to use code or rely on auto-scaling controls. I have stopped using tools to create forms for WxWidgets a long time ago. Making forms in code is pretty straightforward and you can alter things like alignment and spacing with a couple of defines.

[PKTKS]

Hi
I need to develop an application in C / C ++ with a graphical environment for Raspberry, something similar to a video game (although it is not a video game). I have to handle videos with audio, images, texts with artistic fonts, etc.
(..)
Regards

Well pretty much the folks above detailed the 3 options: Qt/Gtk or wxWidgets.

Much different among themselves and none of them are really that kind for  dedicated framebuffers like video games or real time displays.

I have used quite extensively the 3 of them mostly I prefer Gtk pure C API which can link to virtually anything you can think of despite templates hassle  - e.g. templates may be a bless or a total curse in your life among compiler versions and compatible issues

In these cases I  usually fallback to what I think is the compromise:
-  dedicated double-buffers in Gtk - they work really nice despite the layer you have.
- SDL based accelerated API  (www.sdl.org)

The latter can interface Gtk absolute seamless

Done sometime ago a simple DMM interface with  FunctionGen SCOPE/Spectrum Analyser with SIGROK interface in almost a week using Gtk  bindings only...  almost real time tripple buffer threaded API

No template or STL hassle or problems with compiler odds

The real argument is that Gtk version are easier to handle than the messy gtkmm or even the more messy Qt versions...

An order of magnitude simpler faster SDL interface is also piece of cake

ALAS interesting detail that pure C API allowed me to bind JACK transport streams to ALL instruments on these apps.. quite nice way to manage I/O under layer

Hope helps 
Paul