User: Password:
Subscribe / Log in / New account

Clasen: Introducing GtkInspector

Clasen: Introducing GtkInspector

Posted May 18, 2014 8:34 UTC (Sun) by niner (subscriber, #26151)
In reply to: Clasen: Introducing GtkInspector by rahulsundaram
Parent article: Clasen: Introducing GtkInspector

It would be, if it weren't for the KDE Free Qt Foundation:

(Log in to post comments)

Clasen: Introducing GtkInspector

Posted May 18, 2014 12:41 UTC (Sun) by torquay (guest, #92428) [Link]

An extract from the above site:
    This agreement ensures that the Qt will continue to be available under both the LGPL 2.1 and the GPL 3. Should Digia discontinue the development of the Qt Free Edition under these licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreement stays valid in case of a buy-out, a merger or bankruptcy.
That's either the next best thing to having a dedicated non-profit QT foundation, or as good as having it. This leaves pretty much no reason to write new software in GTK.

Clasen: Introducing GtkInspector

Posted May 18, 2014 16:25 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Sorry but no, it is nowhere as good as a non-profit foundation. The current situation is that unlike a non-profit foundation, a single commercial company retains the trademarks, the copyrights via CLA. This is enormous difference in the level of control one company has. The agreement only helps in the worst case scenario of a merger or bankruptcy. It doesn't help with day to day governance of the project at all and I am sure you are already aware of this and don't consider it a substantial risk to the project. I do.

Clasen: Introducing GtkInspector

Posted May 19, 2014 6:51 UTC (Mon) by torquay (guest, #92428) [Link]

I consider relying on a poorly maintained and haphazardly developed toolkit (GTK) as the greater risk. One can wax lyrical about various foundations, trademarks and CLAs ad nauseam, but what it comes down to in the end is that QT is clearly more suitable for Getting Stuff Done™. QT will always be available as open source (no matter what Digia does or doesn't), so the issues mentioned above are of virtually no practical consequence. Instead, they can be interpreted as attempts to prop-up a declining framework, which should have been taken out the back and shot a long time ago.

Clasen: Introducing GtkInspector

Posted May 19, 2014 22:46 UTC (Mon) by ovitters (subscriber, #27950) [Link]

> I consider [..] haphazardly developed toolkit (GTK) as the greater risk

You're not going to be taken seriously if you make statement like above. You dislike GTK, cool. But "switch because I dislike it" is not much of an argument.

Clasen: Introducing GtkInspector

Posted May 19, 2014 23:39 UTC (Mon) by HelloWorld (guest, #56129) [Link]

Why? GTK *is* poorly maintained. Watch at Dirk Hohndel's talk about switching subsurface to Qt. Look at the projects who are switching to Qt such as VLC, Wireshark or LXDE. Switching toolkits is a lot of work, so the fact that people are nevertheless willing to take this kind of pain tells something about GTK.

Clasen: Introducing GtkInspector

Posted May 20, 2014 19:07 UTC (Tue) by lambda (subscriber, #40735) [Link]

I watched Dirk Hohndel's talk, and my takeaway was that most of the issues were based on cross-platform use. In Gtk, running on platforms other than Gnome on X (or Wayland in the future) is a somewhat secondary goal, so while it works OK, there are a variety of platform integration issues and it doesn't really look or act very much like a native application. Cross platform application is precisely what Qt is designed for, and is much more of a core goal. As Dirk pointed out, most of Subsurface's users are on Windows and Mac OS X; it only has as high a percentage of Linux users likely due to Linus's involvement in the project.

I tried looking at a few of the issues they had mentioned where they had talked to Gtk developers and been snubbed, but I couldn't find much. One of them was asking about help on doing custom placement and changing the delay of tooltips, as they wanted to use tooltips to display information about what you were hovering over in the graph. They got a few answers about a few customizations you could do, but the response that to do it really well they'd probably have to implement a custom widget rather than using tooltips. What did they do in Qt? They wrote a custom widget for it.

The other major issue they mentioned was not being able to edit a dive right on the view screen, but having to pop up a separate window for editing. I never quite figured out what problem they ran into there. It would be helpful to point out the actual threads where they had trouble and had to give up in Gtk, because I'm curious about how much wasn't possible in Gtk, versus how much was just easier in a rewrite now that they knew about all of the mistakes they'd done in the first UI due to not being experienced UI developers.

Having some familiarity with both Gtk and Qt, though not a ton of experience, I would say that overall I prefer Gtk if I'm going to be writing Linux-native software, and Qt if I want to write something cross-platform.

Clasen: Introducing GtkInspector

Posted May 20, 2014 19:29 UTC (Tue) by rleigh (guest, #14622) [Link]

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

Clasen: Introducing GtkInspector

Posted May 20, 2014 6:23 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

The sentence you quoted does not translate as "I dislike it" -- it's a pretty accurate observation and a good reason not to use the library. The development of GTK is haphazard, with a utility appearing here, and a new popup widget there, and then no ports to windows, then a port for windows, now everyone port to GTK3, now please don't, wait for GTK4, here a change to the theming system, there a new, and broken, CSS styling thing. It's not something that inspires confidence.

Mind you, if you closely follow Qt development, there's plenty in there that came about in the same fashion -- often the same things, even, like CCS-like styling. The difference is, it's almost always well-documented.

Clasen: Introducing GtkInspector

Posted May 20, 2014 7:34 UTC (Tue) by ovitters (subscriber, #27950) [Link]

Ok, saying again what I stated before: Just repeating haphazard and saying it is true doesn't make people want to read any further.

It seems you repeat what others are saying. I'm repeating it is pretty useless what you're doing. Theming is NOT guaranteed to be stable. Complaining about that or having to resort to that is pretty pointless. Same for other things that you highlight.

Clasen: Introducing GtkInspector

Posted May 19, 2014 8:42 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

Note that GTK does NOT have anything Qt does not: for GTK, there is NO commercial entity which can give out another license if potential customers were interested. For Qt, there is. This is part of the reason why Qt has a lot more code and interests flowing into it, of course, but it doesn't limit anything.

Both code bases are under the LGPL, it is just that in Qt there's an extra option thanks to Digia - for those who pay for it, of course. That payment flows back into Qt as extra money.

This is the same situation as at ownCloud - without ownCloud Inc. there would simply be less development. Otherwise, it would still be aGPL so nobody loses.

Essentially, Rahul, what you portray as a 'problem' is an advantage for the ecosystem. Thanks to the proprietary license, companies like BMW and other large users of Qt contribute (via paying Digia). They would otherwise not or very little, as Open Source just isn't their thing.

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