Re: The Future?

Hi, Emmanuel et al,

On Sun, Mar 10, 2019 at 4:38 AM Emmanuele Bassi via gtk-list
<gtk-list gnome org> wrote:

Meta: having this discussion on gtk-list is probably the best example as to why we need to move to 
Discourse. Nobody involved with the development of GTK even reads this list, except me, so you're never 
going to get more than my opinion about it.

What is "Discourse"?
In the past there was a forum about GTK+ where people could come and
ask questions - it is now dead.
And this list is the only place that known to people.

Meta × 2: while I am employed by the GNOME Foundation to work in GTK, this *my* opinion, and should not be 
construed as anything but my opinion.

On Sun, 10 Mar 2019 at 06:37, Miroslav Rajcic <support notecasepro com> wrote:

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 (

- Wireshark  (

- Subsurface by Linus (

- GCompris educational software (

VLC, Wireshark, Subsurface, and GCompris switched to Qt mostly because of its support for Android and 
mobile platforms, something that GTK doesn't support. Well, Subsurface moved to Qt because the original 
developers thought that asking on Google Plus was the proper way to ask for help with writing GTK 
applications, and had no objections when somebody else showed up and rewrote their application using Qt.

It's entirely justified to go through the ringer of a full rewrite if you're thinking of expanding 
somewhere the GUI toolkit you use is not going to be, and it's highly unlikely that an Android backend for 
GTK will ever materialise—let alone an iOS one—so if you're thinking of targeting Android and iOS, Qt is a 
perfectly valid choice. I personally would recommend using Xamarin.Forms, and stop writing code in C/C++.

The LXDE case is a bit different: writing desktop environments is kind of what GTK is known for. It seems 
that LXDE didn't have many contributors, and the few that were there decided to join forces with a Qt-based 
project in order to increase the contributors base. It's also telling that the Qt port of LXDE is still 
very much in progress, and the GTK2 code base is still being maintained. If porting to a new major version 
of a toolkit is a lot of work, porting to a whole new infrastructure is even more work.

All these people have valid complaints, so someone should think about it.

Everyone involved in GTK thought about them. We incorporated the feedback we gleaned from the various 
ranting into a better stability and versioning guarantees; better tooling, like the Inspector; a better 
build system, to ensure ease of build on Windows and macOS. If the complaint is "it's not written in C++" 
or "there is no paid support" then there isn't much we can do.

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).

There is a fundamental misconception at work, here. GTK was never a cross-platform in the same sense as Qt 
is a cross-platform toolkit. GTK began supporting Windows in the 2.0 release (2002) because GIMP first, and 
then Evolution, needed to build and run on Windows. GTK is a *portable* toolkit, but its goal has always 
been writing Linux (and GNOME-adjacent) applications.

Of course it doesn't mean we shouldn't support people writing non-Linux apps with GTK, but they are a 
smaller target audience.

Plus, you seem to imply that "binary builds for Windows" somehow means "better cross-platform support", 
which is nonsensical at best. Windows support in GTK has *never* been this good. There are multiple 
volunteers working on building, testing, and developing GTK on Windows. It would be great to have as many 
people working on macOS, even though things are moving once again, there.

How about porting recent GTK version to OpenVMS?

Thank you.

  "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.

Yes, things are always "easy" when somebody else is paid to do them for you. Doesn't mean they are easy at 

Given that Tor stopped working on these years ago, and that Windows hasn't stayed still in the meantime, 
the only reasonable course of action for GTK developers was to offload the build of GTK on Windows to the 
MSYS2 package management system—mostly like we do on macOS, with brew and macports. Of course, we would 
have loved it if somebody had showed up and did the work; somebody did, from time to time, and we even gave 
access to a Windows build machine hosted in the GNOME infrastructure, but keeping things building is hard—I 
do that for GNOME, and it's not fun—and people simply tire of it.

The move to Meson for GTK4 (and possibly to GTK3, as a secondary build system) should make building GTK and 
many of its dependencies easier to deal with. Ideally, we'd like for people to be able to clone just GTK 
and be ready to go; of course, that's probably the "blue sky" goal, but it should be easier than Autotools 
has been.

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.

GTK4 has a video and media player abstraction on top of GStreamer, and GStreamer has a GTK3 video widget, 
these days.

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).

I'd actually very much like to get rid of GtkTextView and have a simple, multi-line text entry. Complex 
text editing widgets are *complex*, and everyone has their own use case. Do you want code editing? Do you 
want word processing? Do you want a multi-line text input for forms? A single widget for all of these means 
that the single widget is a mess in terms of implementation and API. I know, because GtkTextView is that 
single widget, and it's a mess.

My personal opinion is that people are much better served by having a rich text editing widget in a 
separate library, targeted at their own use case.

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

I'm so sorry, but I don't see how this is relevant. Your decisions are your own. Supporting Qt4 and Qt5 at 
the same time is going to be problematic *at best*, for instance. If you ever decided to move to Qt, you'd 
have to drop Hildon platforms anyway, for instance.

Dropping GTK2 is perfectly reasonable, now: GTK3 was released in 2011, 8 years ago. At this point GTK3 is 
almost as old as the whole GTK2 development cycle.

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)

Drag and drop is one of the API sub-systems that was implemented as a thin layer around X11 concepts for 
GTK 2.0 (back when it was standardised across toolkits), and that has never been heavily touched. We're in 
the process of rewriting both clipboard and DnD support in GTK4—using a stream-based API and negotiation 
based on MIME types—so it's going to be easier to use, even with complex data types.

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)

2.16 was released in March 2009, 10 years ago. I assume things have changed in the meantime. Did you at 
least file a bug? Which platform are you referring to?

Deprecations happen. They are *the only* way for us to move the toolkit forward without breaking API every 
2 years. Deprecation means "this is not going to be a maintained API going forward, so if a bug happens, 
you'll have to be proactive and help us with the fix instead of just filing an issue". We've made progress 
on communicating what is deprecated, these days; compiler warnings, run-time warnings, porting 
documentation. We can do better, of course. Just don't expect us to never deprecate things, because that 
is, essentially, asking us to never change the toolkit.

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.

First of all, those "shiny things" are what allows us to get more people using GTK, and possibly 
contributing to GTK. We would have long since been dead as a project if all we ever cared about was making 
current users of GTK happy forever.

Additionally, every platform has switched to using GL/Vulkan/Metal for rendering their UIs; using a common 
layer for rendering is basically necessary to remain relevant and portable.

As I said above, we have been working on making GTK easier to use on other platforms—even if, and it bears 
repeating, our goal is to ensure people can port their code to other platforms, not target them. Yes, it 
would be nice if we had 100+ engineers working on this project full time, but the current full time 
complement of people working on GTK is *2*, and everyone else is either paid part time, or completely 
volunteering. This means we have to prioritise things, and making GTK work on Linux/GNOME will always be 
the priority because of the sheer amount of contributors using GTK on GNOME. Want to flip the balance? 
You'll have to start working on GTK.

Hard-to-implement things like an advanced text editor do not seem to be an a table.

They are on the table only if somebody shows up and does the work. Did you file bugs about the shortcomings 
of GtkTextView? Have you prototyped what kind of API you'd need? What kind of features you'd want? Did you 
write a strawman proposal for a rich text editing widget? Or did you expect us to come up with a new widget 
and present it to everyone? Because that's *never* going to work.

For the GTK4 cycle we "just":

 - redesigned the way GTK draws itself from the ground up
 - added 3D transformations for widgets
 - re-designed the input system
 - rewritten the clipboard and DnD sub-systems
 - we're in the process of dropping a new, responsive layout machinery
 - we're going to add an animation framework usable programmatically and not just through CSS transitions

All things that were highly requested for years; people prototyped them out of tree, where possible, or 
wrote extensive descriptions of how they should work *first*.

Text editing is another high priority task, but currently people are asking for a better code editor in 
GTK; nobody is asking, or working on, a rich text editor to replace TextView.

This was meant as an constructive critics, it seems strange that this topic got just one answer so far.

See above, re: the meta paragraphs.


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> 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 

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

gtk-list mailing list
gtk-list gnome org

[@] ebassi []
gtk-list mailing list
gtk-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]