Other Which GUI library should I use?

lvivtotoro

lvivtotoro

I am a JavaFX developer but am slowly (trying to) switch to something in C++ that supports FreeBSD.

I considered Qt, but it's license is a bit unappealing to me.
What other libraries are there?
 
I've been playing with Nana lately. It is written in modern C++ under the Boost Software License.

Nana includes a Code Blocks project file for folks that use Code Blocks but you are not limited to Code Blocks as your IDE choice.

https://github.com/cnjinhao/nana

Documentation is here:

http://nanapro.org/en-us/

To make it easy to build on FreeBSD, I've submitted a PR to the project owners.

https://github.com/cnjinhao/nana/pull/288

Three other noteworthy GUI projects are Nuklear (strict C), Dear Imgui (C++) and NanoGui.

Nuklear and ImGui are MIT licensed. Both are focused on gaming / fast frame rates. You choose the graphics back-end - eg. X11, OpenGL, etc.

https://github.com/vurtun/nuklear
https://github.com/ocornut/imgui

NanoGui is BSD licensed but relies on multiple other libraries with varying licenses. It has the most dependencies of all four.

https://github.com/wjakob/nanogui

Nearly all of the above are portable to Linux, Mac OS X and Windows.
 
If you want to use a GUI builder, then Gtk+ and Glade are a very good pair.

However, if you prefer everything in code then wxWidgets I find to be a little bit more "obvious" in naming and how things work.
The wxBoxSizer is quite similar to the javax.swing JGriBag that you may have used.

wxWidgets is also a little bit better supported on Windows if cross platform is important.
 
lvivtotoro said:
I am a JavaFX developer but am slowly (trying to) switch to something in C++ that supports FreeBSD.

I considered Qt, but it's license is a bit unappealing to me.
What other libraries are there?
Click to expand...
Please develop with Qt, all the GTKs are BS.
 
Are you looking for a quick, light setup for GUI development, or a full blown toolkit that covers A-Z? Does the GUI need to be glitzy? Most people overlook the X11-toolkits/fltk port, which restricts itself to addressing only the GUI (unlike Qt, which tries to cover everything). The license is lgpl2, but an exception allows static linking. It's very small, only covers the GUI, and typically adds as little as 100k to a "hello world" style program.
 
SirDice said:
And I prefer Ford over Vauxhall/Opel. See what I did there? Statements like this are meaningless unless you explain why you prefer one over the other.
Click to expand...
It would be long, and I'm not good at English, cann't fully express my thoughts and will cause a lot of misunderstandings, and holy war between fan of the two toolkit. You found my post to be meaningless, you're free to skip it.
 
giahung1997 said:
and holy war between fan of the two toolkit.
Click to expand...
They typically start with statements like "use X because Y is crap" without any (technical) arguments as to why it's crap. You won't start a holy war if you explained the rational behind your discussion. Otherwise your statement would simply be considered trolling and that will definitely start a holy war.
 
SirDice said:
They typically start with statements like "use X because Y is crap" without any (technical) arguments as to why it's crap. You won't start a holy war if you explained the rational behind your discussion. Otherwise your statement would simply be considered trolling and that will definitely start a holy war.
Click to expand...
Mine differ experience. If I don't argue further why it's BS, it's just my personal opinion, no one can attack me. In my country, if I clearly state why, they'll immediately jump at me and from their mouth pouring "you're idiot", "you don't know everything", "you lack of knowledge", etc... and when they decide who's right I'm always lose, they show their degree I've none :(
 
With libraries, tools or whatever there's always two reasons why someone uses X instead of Y. The first reason is technical merits. Is it technically a good tool, library or whatever? Does it work properly and correctly? Has it been designed well? Those merits can be discussed surely. Maybe there really is a better way to do things. The second reason however is a little more difficult. It's personal preference. Even if tool X is technically better I like to use tool Y. And that should be respected.
 
giahung1997, What are your views on Qt's use of MOC rather than using pure standard C++? In 10 years time when Qt8 is out and no-one is really supporting the older Qt5 anymore, will it not become a maintenance nightmare trying to get Qt5's version of MOC working with (the then) modern build systems like cmake 6?

One thing I definitely recommend thinking about with GUI libraries is build system support (and certainly future support). Purely because even migrating between newer versions is such a time consuming, error prone and thankless refactoring task.
 
kpedersen said:
giahung1997, What are your views on Qt's use of MOC rather than using pure standard C++? In 10 years time when Qt8 is out and no-one is really supporting the older Qt5 anymore, will it not become a maintenance nightmare trying to get Qt5's version of MOC working with (the then) modern build systems like cmake 6?

One thing I definitely recommend thinking about with GUI libraries is build system support (and certainly future support). Purely because even migrating between newer versions is such a time consuming, error prone and thankless refactoring task.
Click to expand...
I appreciate ease of development over such thing as MOC. C++ standard are terrible, more and more increase the language complexity. Keep writing code, thing you wonder in the future the Qt forks will handle, we don't have to care.

About Qt's fast releasing model, Qt has LTS, compilers have LTS, too. Your GTK in this aspect sucks more than that, GTK 3.x not compatible with GTK 3.y, API breaks, will have to have multiple versions of GTK 3.*... Many Apps still not migrated from GTK2 to GTK3. It's sucks more than you ever think about.

Again, ask yourself why PCBSD folks use Qt to write their GUI Apps, not your sweet GTK. Be realistic.
 
giahung1997 said:
I appreciate ease of development over such thing as MOC. C++ standard are terrible, more and more increase the language complexity.
Click to expand...

I think you misunderstood my point. Newer C++ standards are coming whether you like them or not. Using MOC for the signal / slots system rather than the standard C++ bind or lambda systems presented in C++11 is risky in terms of future portability.

Also, if you do not appreciate modern C++ standards... perhaps give Gtk+ a try... It is C, not C++ ;).
And yes this does make Qt an unsuitable choice for a lot of Unix-y projects which *are* written in C and not C++.

giahung1997 said:
Keep writing code, thing you wonder in the future the Qt forks will handle, we don't have to care.
Click to expand...

This is simply not an appropriate mindset for a large number of projects. Have you ever tried to maintain or upgrade a Qt 1 project to a modern UNIX running Qt5+? Stuff breaks and *you* need to fix it, not the Qt developers.

giahung1997 said:
About Qt's fast releasing model, Qt has LTS, compilers have LTS, too.
Your GTK in this aspect sucks more than that, GTK 3.x not compatible with GTK 3.y, API breaks, will have to have multiple versions of GTK 3.*... Many Apps still not migrated from GTK2 to GTK3. It's sucks more than you ever think about.
Click to expand...

LTS does help... But I can't even find Qt versions lower than 3 in the FreeBSD repos... I can however find Gtk+ 1. This actually makes Qt a massive deal breaker for me. Heck I still like to use Motif for some of my personal projects ;)

giahung1997 said:
Again, ask yourself why PCBSD folks use Qt to write their GUI Apps, not your sweet GTK. Be realistic.
Click to expand...
I feel you are being a tad religious about Qt compared to Gtk+. Also... why PCBSD as a reference? Surely you could have found a more impressive example. For example Oracle's Solaris 11 uses Gtk+ as part of their enterprise Gnome desktop or RedHat uses Gtk+ as part of their enterprise Gnome desktop. It is still a completely moot point.

Besides Gtk+ and Qt, I often use wxWidgets... Once their Qt back-end becomes more mature, I couldn't give a flying fsck(8) what underlying toolkit it uses.
 
kpedersen said:
I think you misunderstood my point. Newer C++ standards are coming whether you like them or not. Using MOC for the signal / slots system rather than the standard C++ bind or lambda systems presented in C++11 is risky in terms of future portability.

Also, if you do not appreciate modern C++ standards... perhaps give Gtk+ a try... It is C, not C++ ;).
And yes this does make Qt an unsuitable choice for a lot of Unix-y projects which *are* written in C and not C++.



This is simply not an appropriate mindset for a large number of projects. Have you ever tried to maintain or upgrade a Qt 1 project to a modern UNIX running Qt5+? Stuff breaks and *you* need to fix it, not the Qt developers.



LTS does help... But I can't even find Qt versions lower than 3 in the FreeBSD repos... I can however find Gtk+ 1. This actually makes Qt a massive deal breaker for me. Heck I still like to use Motif for some of my personal projects ;)


I feel you are being a tad religious about Qt compared to Gtk+. Also... why PCBSD as a reference? Surely you could have found a more impressive example. For example Oracle's Solaris 11 uses Gtk+ as part of their enterprise Gnome desktop or RedHat uses Gtk+ as part of their enterprise Gnome desktop. It is still a completely moot point.

Besides Gtk+ and Qt, I often use wxWidgets... Once their Qt back-end becomes more mature, I couldn't give a flying fsck(8) what underlying toolkit it uses.
Click to expand...
Usually I'll thank a post I think useful, your post isn't. You have to deal with very ancient codebase, the OP have to write from scratch. It's different. You said I'm religious about Qt, you are with Gtk, too. I think I shoudn't talk with you anymore, because it'll go nowhere. Keep faith on your Gtk while the rest of the world moving to Qt.
 
lvivtotoro said:
I am a JavaFX developer but am slowly (trying to) switch to something in C++ that supports FreeBSD.

I considered Qt, but it's license is a bit unappealing to me.
What other libraries are there?
Click to expand...
Keep in mind OP, the world constantly change. Never keep an old faith with a rusty mindset. Qt now LGPL, you can use it for commercial without having to pay anything. You said you come from JavaFX world, you'll find QtDesigner to be familiar (to Gluon, am I right?). If you want a GUI designer for Gtk, there is Glade but it's noway comparable to QtDesigner, don't choose the wrong way then realize you're stuck with it. Best regards.
 
giahung1997 said:
You have to deal with very ancient codebase, the OP have to write from scratch.
Click to expand...

I think you missed the point. Almost all codebases start new. However after 5 years they inevitably become "old". Working with old codebases can be complex unless certain informed choices are made early on.

giahung1997 said:
You said I'm religious about Qt, you are with Gtk, too.
Click to expand...

Again, I think you missed the point. I already mentioned in my post that I deal with almost all existing Gui toolkits on a number of projects. This has given me experience in their use but most importantly I know about a couple of their gotchas.

Like I said, I use Qt for many things, I am just a bit weary of MOC.
 
lvivtotoro said:
I am a JavaFX developer but am slowly (trying to) switch to something in C++ that supports FreeBSD.

I considered Qt, but it's license is a bit unappealing to me.
What other libraries are there?
Click to expand...

None, all graphical libraries for Unix-like systems seriously suck. The best is to get used to termcap or ncurses, it IS reliable.
 
Indeed there are many toolkits in C++ out there, already mentioned GTKmm (C++ wrapper around GTK), QT, FLTK, Ultimate++, Nana, and probably a dozen more. It is very much a personal preference (or your company preference, more often). None is superior over the others.

However I would like you to reconsider whether C++ for GUI development is really what you need. One prominent Lady in C++ community said that C++ is not really the best choice for GUI development and I tend to agree. Not that it cannot be used, to contrary - see the number of Toolkits, but do you really need raw power of C++ code for plain everyday's GUI? Does it need 90 FPS rendering? Are human beings able to notice whether refresh took 2ms or 7ms? etc, etc. As long as it has acceptable performance end users do not care.

Recently I tried TCL/Tk for user frontend and found it quite powerful for GUI development in a truly cross platform manner. The whole trick is that you can use higher level, easier to develop languages for front-end part and interaction with user (button pressed, show this, show that...), while backend may still run on some more robust compiled code and communicate with GUI via sockets locally or remotely.
Your choice, you know your needs.
(disclaimer: I am a C-like-languages biased person and learning TCL did not go without quite a few WTF's but it took only couple of hours to learn and writing app was in a fraction of time I would need for coding the same GUI in C++)
 
The best would be to use FLTK, which is not eating huge amount your memory.
Bonus +1: you may compile on mac or windows.

The good alternative (for Linux mostly) is to use libx11-dev, and you are sure that you can make from scratch nice applications, reliable + in plain C !!

But, X11 will be abandoned soon or later. Joy of Opensource and unstability of graphical applications.
It is perfect for Redhat, Google, ... which make profit ($) out of new libraries and bloated graphics. New PC, New OS to be installed, needing more RAM, ... incredibly slower Firefox with i20 processor ;) ... new powerplants, new solar panels,... good for CO2 increase and destroy our planet !!
 
"According to the internet", the world "is moving" to Qt, GTK is dead, blabla.

I am just a FOSS user with amateurish coding skill. For the rest of this post, keep in mind that my beloved language is C, Python comes 2nd and I can't grasp C++. Basic OOP C++ is fine but all those year of adding OOP abstraction to the language make some C++ usage impossible to understand for me.
I use as much Qt5 that I use GTK.

Consider starting a project with Python3 and PyQt5. Python's fast prototyping + Qt5 because internet says so. You try to separate the core functionnality from the GUI code but you realize that Qt5 provide a lot of convenient classes (for process, networking, audio, etc...) and you start to write everything with Qt objects since Qt classes works so well together.
Qt is not only a GUI toolkit, it is a framework.
I prefer loosely coupled application but I find hard to restrain myself from using more than just QtGui module.

Then you want to jump from your prototype to a compiled language, for reasons. Let's go native with C++.
If I believe correctly, you need to add Q_OBJECT in every class that inherits a Qt one. The makefile is huge and editing it by hand is unreasonable, you need qmake because of MOC.
To me it looks like you are developping in a superset of C++.
I really hope Qt abandon the MOC in favor of a more C++ idiomatic solution. Also I would like to have human creatable makefile for Qt-based project.

Which brings me to wxwidget.
While coding in C++, wxwidget is more comfortable for me to use than Qt. Vanilla C++, and classic makefiles.

But if you are like me a C person and are willing to use a compiled language, the easy solution seems to be GTK+.
I love OOP in C, I learned a lot about memory and OOP concept like that. GTK and GObject are good examples of C-OOP.
Also using GTK in a project only involve using a pkg-config command in the makefile. So human made makefile are not a problem.
So you rewrite your program in C+GTK only to discover that it is not really portable outside of linuxes and BSD. Also it is full of Gnome idiosyncrasies.
If GTK1 was the GimpToolKit, GTK2 could be read as (linux)GuiToolKit. GTK3 is clearly GnomeToolKit. So if you don't follow Gnome/redhat lead and would like something C-based, there is no clear solution.
You can find GTK2 lib compiled for windows somewhere. It's 20MB ...
I am not sure there are GTK3 ones, unofficials maybe.
As a side note, I like GTK API but it seems to me it lacks methods that Qt have. I couldn't find how to create a trayicon for my program with GTK3, it is possible with GTK2 but you can't show a popup (whereas with Qt it is very easy).

So Qt brings a lot of stuff (moc Q_OBJECT, makefiles) but it's only apparent when using compiled languages. You will "need" their tools (qmake, qcreator is a must, qassistant for the doc etc ...). So entirely jumping into qt ecosystem is a good idea but it is not completely a chore since the qt project's quality is high.
GTK is gnome's stuff. 2 was cool, 3 is disappointing. But it is "simple" and easy to build you program loosely coupled against it.
wxwidget is sane, simple, smooth (it is C++).

P.S: There is nuklear a C toolkit. I looks portable.
 
You must log in or register to reply here.
Back
Top