User: Password:
Subscribe / Log in / New account

Clasen: Introducing GtkInspector

Clasen: Introducing GtkInspector

Posted May 20, 2014 22:25 UTC (Tue) by rleigh (guest, #14622)
In reply to: Clasen: Introducing GtkInspector by tristanb
Parent article: Clasen: Introducing GtkInspector

While I think this is indeed the direction things are going in, I think it may be the death knell for GTK.

I'm working on developing cross-platform free software libraries and applications, both for my paid job and for my own projects. They all build on Linux, FreeBSD, MacOS X and Windows and build using all of GCC, clang, mingw and MSVC. They are typically using C++(11) and Boost and other standard free software C and C++ libraries for the core functionality, and Qt for the UI where applicable. In other words, the free software I produce is available to about as wide an audience as I could hope for by deliberately making the software as portable as I can (with not all that much extra effort). I would have liked to have had the choice to use GTK+ here, but it's no longer a contender, lacking robust cross-platform support for MacOS and Windows, which is a shame. And it's increasingly unsuitable for non-GNOME Linux development too. And FreeBSD isn't exactly cared for either.

The question I'd like to pose is that, if GTK is not for serious cross-platform application development, what *is* it for? At a stroke, being Linux-only and GNOME-only eliminates a huge number of application developers. Probably most of them. And these are the people who will be pushing and testing the toolkit to the limits, and also hacking on it to improve it, add new widgets and fix bugs. Even if they aren't core maintainers. I was once one of these people for GTK+, but not since it became clear it wasn't being maintained well, and didn't have a future. And I take no pleasure in saying that--I invested significant time, both my own and company time, over the course of several years, in working on GTK+ applications and on GTK+/GLib including a lot of testing and bugfixing of its Cygwin and MinGW support across the whole set of GTK+ and base GNOME libraries (again: for cross-platform development back when we had hopes that GTK+ was good for such things). Ultimately, that was a wasted effort given where it's led to.

I don't think the Cocoa comparison is good for GTK+. It's a niche toolkit which you would use if you only want to target MacOS. True for some applications for sure, since MacOS has a large number of users, but not the majority. By restricting GTK+ to Linux/GNOME, you similarly limit the scope for its use and hence relegate it to a niche. And in the wider picture, GNOME on Linux is a very tiny niche. Very few application developers will wish to limit themselves in this way--the focus is on the application, not tying oneself to a barely significant desktop for little tangible benefit. GTK+ may well survive in this niche, but without any real incentive to use it, it's not likely to prosper.

(Log in to post comments)

Clasen: Introducing GtkInspector

Posted May 21, 2014 14:09 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> Ultimately, that was a wasted effort given where it's led to.

I'm sorry that you think so but if you got utility out of it at the time commensurate with the work you put into it, even if it isn't the future, then it wasn't a wasted effort. We don't need to be so attached to our particular systems that we are excessively loss-averse to changing how they work or changing to different systems altogether if the first one doesn't work out for whatever reason.

If GTK+ doesn't work out and gain significant traction outside of the GNOME desktop internal utilities, it still had a good run and it was useful to people for a time.

Clasen: Introducing GtkInspector

Posted May 23, 2014 9:16 UTC (Fri) by rleigh (guest, #14622) [Link]

In this case I'm afraid so say I got precious little utility out of it, after putting in many months of effort, so I do regard it as an unfortunate waste of time. Other than a salutory experience in how not to do things.

For both GTK+ applications and programs making use of GLib/GObject, I ended up spending over half my time working on and around bugs in the libraries and in the overhead of using GObject (I really can't stress how much the maintenance burden seriously hinders refactoring and introduces bugs). That's time I should have spent working on the applications themselves, so that's a serious cost to pay. Taking a few weeks out to convert some of them to pure C++ was one of the best decisions I have made, and really made a dramatic difference to their robustness and maintainability, and hence the time I could devote to actually developing the applications as opposed to dealing with GObject issues.

GObject requires "heroic coding", the attitude that in the face of a fragile API, it's not important because "I'm such an amazing programmer, I'll just not make any mistakes". Now I'm older and perhaps a bit wiser, I increasingly see the great value in having the compiler pick up as many errors as possible; having it silently pass over errors is simply unacceptable. I know that I'll make some stupid mistakes, and I want them to be caught early. Have you read the sources for a big application using GObject, such as Gnumeric? I have the utmost respect for Jody Goldberg, it's a great piece of work. But there's a reason people aren't writing more GTK/GNOME applications: this stuff is terrible to maintain and refactor. The same code in C++ would be more readable, maintainable and robust, and not just by a small amount.

Clasen: Introducing GtkInspector

Posted May 23, 2014 18:53 UTC (Fri) by welinder (guest, #4699) [Link]

> Have you read the sources for a big application using GObject, such
> as Gnumeric?

I have. In fact I wrote most of it.

There isn't a whole lot of GObject code in Gnumeric. The dialogs are all made with Glade with C code to implement the things that happen when you push buttons. _That_ code wouldn't look at whole lot different in any other language.

The hairy parts of the Gnumeric code are (1) the dependency code that tracks which cells depend on which other cells, and (2) the quad tree used to store cell formatting. Neither is related to GObject and both would look roughly the same if written in C++.

Re. refactoring: our graph engine has long been factored out and is used in other applications.

That said, I do agree that Gtk+ and the never-ending stream of ABI breaks and "deprecations" that come with it is a pain. I think that's a problem with the current set of Gtk+ maintainers more than with Gtk+ itself.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds