User: Password:
Subscribe / Log in / New account

Clasen: Introducing GtkInspector

Clasen: Introducing GtkInspector

Posted May 21, 2014 14:09 UTC (Wed) by raven667 (subscriber, #5198)
In reply to: Clasen: Introducing GtkInspector by rleigh
Parent article: Clasen: Introducing GtkInspector

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

(Log in to post comments)

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