Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Runtime libraries, getting started
Michael_x last edited by
We have some c++ driver software with a tiny User Interface. All ok (more or less) on Windows VisualStudio.
Now it is to be ported to Linux. The c++ driver itself is fine in gcc, building it via cmake.
Now I am looking for a convenient tool to build the GUI dialog and guess that Qt might be more convenient than GTK+ (or other ?)
I don't know either and search for the one with
- the lowest learning efforts
- the least overhead to bundle to our software
- sufficient support to help with 1)
So here's Question #1:
After clicking the first tutorial in windows, I found that the 15k exe needs a lot of helper dll files. How does deployment work here and on linux? How do I find out, which other files I have to supply, or which I can expect on standard repositories for linux.
After my "hello world" exe tutorial, I want to learn how to build a .dll / .so to separate the GUI stuff from my main code. The GUI would just be called with some parameter data to show a dialog, return some collected/modified user input and probably would access an external callback function for a Test button.
This is roughly how the VisualStudio approach works currently.
Any hints where to find samples / tutorials most close to such a goal? I see there's a lot of stuff to study, and I fear to get lost in fancy features, which are certainly great, but I'm rather lazy.
Rondog last edited by
For GNU/Linux maybe KDE or GTK+ would be the best. You would only need to deal with your application and custom files as everything else would already be installed. I believe the majority of users using GNU/Linux with a GUI will either use the KDE or Gnome desktop. KDE is an offshoot of Qt so if you are familiar with how Qt works you can pick up on KDE quite fast. The only downside is if you have a KDE desktop and your application uses GTK+ or visa verse. This would be one advantage of using Qt over either of those two but this does require the Qt libraries to be installed.
One cross platform framework I looked at some time ago was FLTK. It is a very light and designed to be statically linked. If you only want to provide a simple GUI that is light this might be an option. It is a bit rough but looks like it has everything needed. FLTK Help.
My impression is that you are not interested in the GUI part at all other than to create one for your application to make it easier to use. Something like a single executable file with no dependencies that works on all systems.
A Former User last edited by A Former User
Generally speaking, deployment on Linux is a nightmare (no matter what toolkit you use). You can either deploy all the dependencies together with your application (preferentially statically linked) which leads to less problems but huge binaries, or you rely on the package management systems of all the billion Linux distributions out there, which means you have to create specifically targeted installation packages (*.rpm, *.deb,..... files) for each distribution and version you want to support.
If your Windows software is already finished then it might be the easiest way to make it work under Linux's Win32 ABI ("wine").
On the Qt-or-Gtk-thing: Gtk is a mess. Qt is great. But I don't want to start a flamewar on that.
Michael_x last edited by
Thanks Rondog and Wieland,
I'm a step further since my day 0,
learning that SIGNAL / SLOT is rather basic than fancy und learning that deployment on windows is doable, but involves much more than I imagined initially.
The only good thing regarding "deployment on Linux" (agreeing with you, Wieland) is that more Linux users seem to be satisfied with manual installation instructions ( get this version of that opensource software ) than in the windows world.
@Wieland: thanks for the hint, but Wine is not a way to go, unfortunately.
@Rondog: "very light and designed to be statically linked" are appealing criteria, I'll have a look at FLTK, too.
Thanks, perhaps this account is still useful in the future ;)