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:
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
feature?
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@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list