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.



On 9.3.2019. 17:43, Paul Davis wrote:

On Sat, Mar 9, 2019 at 5:19 AM J.Arun Mani via gtk-list <gtk-list@gnome.org <mailto:gtk-list@gnome.org>> wrote:

    2. How does Gtk address the issue of its users moving to Qt?

What evidence is there of this? Who are the "users" of GTK that you're referring to? Moving an existing GUI app between toolkits is typically almost equivalent to a complete rewrite, so applications (which are the real "users" of a toolkit) generally do not move. Developers may start new projects using Qt having previously used GTK, but who counts this? How would we judge if it is significant?

    3. What makes them move to Qt? Why can't Gtk have that respective

Qt has as many issues as GTK once you start using it for complex, deep applications. Different issues, to be sure, but no GUI toolkit gives you a free ride.

Qt is also developed using a different licensing/income generation model than GTK, which changes quite a lot.

Qt mostly has distinct advantages over GTK, and to be honest if I was starting cross-platform development now (22 years after I actually did), I'd probably pick Qt for all the obvious reasons. But it's fairly pointless to ask "how can GTK be more like Qt?" when there's more or less no chance or pathway for that to happen. As it is, I don't do mobile so GTK's issues there don't affect me. I also have 75k lines of code that would have to be almost completely rewritten to use Qt, with no noticeable benefit for our users and only marginal benefits for our developers.

Speaking of "why can't?", why can't I write a C application using Qt  ? :))

gtk-list mailing list
gtk-list mailing list

Reply via email to