|
I think the question is a valid one and there is a plenty of evidence of people moving to Qt due to some issues of GTK. Some notable examples: - VLC
(https://ubuntuforums.org/showthread.php?t=316155&s=54b259f2cb2d1a30ca8dc269d0561537) - Wireshark (https://blog.wireshark.org/2013/10/switching-to-qt/) - Subsurface by Linus (https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-qt/) - LXDE desktop (https://www.zdnet.com/article/lxde-waves-goodbye-to-gtk-in-merge-with-razor-qt/) - GCompris educational software (https://mail.kde.org/pipermail/kde-edu/2014-February/007950.html) All these people have valid complaints, so someone should think about it. Same as Paul, if I would start cross platform now (I started in
2003), Qt would be a no-brainer choice. My personal issues with GTK in comparison to Qt: 1. GTK is not so cross-platform anymore: on Windows and macOS, you are supposed to build your own library binaries (gvsbuild for Windows and jhbuild for macOS exist, but are not foolproof). "Golden age" in this regards was when Tor Lillqvist was still
doing the Windows builds regularly on each GTK release. GTK was easy to be used on Windows at that time. 2. QT has more complete stack, for example integrating
audio/video playing module (Phonon). gstreamer as an alternative
for such module in GTK suffers from "build your own binaries"
(i.e. issue #1) and a more complex interface. 3. for me, this one is huge: QT has much better rich text editor widget (QTextEdit), supporting tables, all types of bulleted lists etc.. GTK's default widget GtkTextView (nor GtkSourceView) is not nearly close to this (no tables, no bullets, no htmL export). For advanced editor you are supposed to embed WebKitGTK, but you must first suffer through issue #1 and use complex JScript solutions to implement your rich text editor features (formatting actions, text change notifications). 4. API stability: jumps from GTK2 to GTK3 were painful, many APIs were changed, what it looks like from here, without the strong need, but just to make everything better organized or similar, without thinking of library users. I have an app that must support GTK2 (even using hildon interfaces on old platforms like Maemo) and GTK3 in the same code base, so it is now littered with many #ifdef layers 5. Many other parts are unsolved or hard to implement in GTK (drag and drop integration using types other than the basic ones, for example) 6. Useful features deprecated, an example is native print preview, that worked in 2.16 if i remember correctly and was broken forever in next releases (at that time I did not want to port preview to a new mechanism, so i had to remove that feature in my program) IMO, it seems that GTK does not have a coherent strategy when it comes to toolkit features and a cross-platform usage (i.e. lowering the effort needed to develop for all major OSes). Nowadays it is mostly focused on adding shiny things as support for shaders, animated transitions, GL rendering. Hard-to-implement things like an advanced text editor do not seem to be an a table. This was meant as an constructive critics, it seems strange that
this topic got just one answer so far. Regards, Miroslav On 9.3.2019. 17:43, Paul Davis wrote:
|