User: Password:
|
|
Subscribe / Log in / New account

Clasen: Introducing GtkInspector

Clasen: Introducing GtkInspector

Posted May 20, 2014 19:29 UTC (Tue) by rleigh (guest, #14622)
In reply to: Clasen: Introducing GtkInspector by HelloWorld
Parent article: Clasen: Introducing GtkInspector

It's been poorly-maintained for over a decade. When I was using it in commercial projects around 2004-5 I was finding bugs regularly and filing bugs with patches in bugzilla (and bugs with stuff along the lines of "this is the bug, these are the options for fixing it, let me know which you prefer and I'll go and I'll fix it and give you the patches later in the week"). The company I worked for was happy for me to do that; they would probably have felt the same way for Qt. Most never got a reply and the patches were generally just left languishing. At the time these unfixed defects became a massive liability for the projects I was working on. I mean, what more could I have done? I'd found the bug, made the fix, submitted the patches... and then nothing. In the meantime I was hacking around the defects waiting for a new release containing the fixes, which never arrived. In the end, these internal projects never saw the light of day, but depending on it working reliably and also working on non-Linux platforms was dicey then and still is today. At the time, the principal reason to go with GTK+ over Qt was the licensing; it was technically inferior even then, and that was the one factor which swayed things. The (then) lighter resource requirements were a very minor consideration. The main change is the Qt licensing. There's now little reason /not/ to use Qt, GTK+ has few points in its favour today.

Here's one I got a message about this week by coincidence:
https://bugzilla.gnome.org/show_bug.cgi?id=308769
It would have been fixed by July 2005 had there been a reply saying "yes, fix it this way". This is a rare one which actually got a reply, but still no productive outcome. As it is, it's probably still broken (can't confirm, I ditched it soon after since I needed a working tool).

Just as a general comment on the CLA situation. I generally dislike them. But. If a project won't review and apply patches for bugs which are major blockers for their end users in a timely manner, who cares if it has a CLA or not? It's simply not safe to rely on either way. The above example was a non-critical example, but it blocked the use of UTF-8 strings in C sources which blocked the i10n/l10n of an entire project until we replaced the broken tool. There were plenty more serious ones at the time.


(Log in to post comments)


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