For the past few months I have been working on a simple windows notepad like text editor. It’s nothing special, but when I first switched to linux I looked around and it took me a while to find leafpad. Unlike leafpad however, Janus uses gtk3, a much more modern toolkit then gtk2, it can display and modify binary data, and it can highlight code syntax for most popular languages. Feel free to check it out on the github.
even more obvious question, why not Qt?
This was mainly because I don’t know C++ but I do know C.
Outside of that, I generally sway more towards gtk apps then qt apps and I use Budgie, so it fits in with my desktop better. Gtk also seems to be more widely used than Qt on linux. And Qt seems to delegate more of its functionality to standalone libraries, which means more dependency tracking which I am very opposed to, whereas Gtk packages one library that encompasses most of the libraries functionality (although I don’t know enough about qt to be sure if this is the case).
As someone who is trying to develop my own Linux destkop apps, I can tell you that the day that I switch to Qt is the day Qt provides a feature that works as well as GObject Introspection (GI) does for Gtk. GI creates a cross-platform database of objects, properties, and signals, for auto-generating language bindings, so you can customize your Gtk programs with scripting languages (Python, Lua, Vala, JavaScript, Scheme). It is a relatively simple task to bind any programming language to GObjects thanks to GI.
Qt does have a QMetaObject system which is similar, but C++ is a difficult language to bind to on most operating systems because of how native language functions are labeled in the library code – names are “mangled”, a hack to work around the miss-match between object libraries features (
.soor.dllfiles), which do not provide the ability to “overload” functions, and C++ libraries features, which do provide this ability. The function/method overloading feature is used quite often in any C++ program. But decoding mangled names for language bindings can be very error-prone without the sort of automation that GI provides.As it is now, really the best way to develop Qt apps is to use C++, with Python for scripting, because these languages are the most well-supported by Qt (C++ natively, Python being the most stable and well-maintained “foreign” language for Qt). And I like neither of these two language. Gtk gives you a much larger selection of scripting language choices, even though it is programmed in C, and this is thanks to how well GObject Introspection works.
I think your use case/justification may not be applicable to the majority of GUI app developers. I have been using both professionally for at least 15 years and IMO without a doubt Qt is so much easier to use, read and work with it’s not even a comparison. When even Linus Torvalds cannot figure out Gtk or get non-rude useful help on it and jumps ship to Qt instead, I think that says it all. Plus in comparison to Qt there are almost no commercial outfits using Gtk professionally and selling products based on it.
I also use Qt professionally, and it is indeed an excellent GUI library. I have absolutely no complaints with how well it is designed and how easy it is to use, and I am consistently amazed by how beautiful the results are, especially with desktop environments like KDE Plasma.
My complaint, which is really a deal-breaker for me, is that Qt effectively forces you into using C++ and Python and/or QML+Quick. For the non-professional software I develop, I want my apps to be scriptable by end users, and I do NOT want to force them to choose between only Python or Quick as their scripting language. For building scriptable, truly cross-platform GUI apps, Gtk is the only game in town.
Gtk is much harder to use only if you are coding in C, because it depends so heavily on the C preprocessor to hack together the infrastructure that C++ has built-in. But because it is so easy to bind scripting languages to Gtk, you only need to program a few very core features in C, the rest you can program in any scripting language of your choice. This very important feature I think is a worthwhile trade-off for making it harder to code in C, especially if you are able to code the larger portion of your application (which is almost always the case) in a scripting language like Lua or Scheme. (Although I admit, most Gtk scripting is done in Python, just as it is with Qt.)
Perhaps, but I would point out that both Canonical and RedHat (now IBM) are both heavily invested into developing Gnome, and I believe most of the paid Gtk development has been funded by these two companies.>