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

Clasen: Introducing GtkInspector

Clasen: Introducing GtkInspector

Posted May 17, 2014 4:21 UTC (Sat) by torquay (guest, #92428)
Parent article: Clasen: Introducing GtkInspector

In comparison to GTK, Qt has a thriving (and helpful) development community, has more features, is better maintained, has more responsive developers, etc. See for example Dirk Hohndel's talk about his experience with switching away from GTK, and the reasoning for LXDE moving to QT.

So what is exactly the point of GTK, given that Qt is also licensed under the LGPL? It seems like a needless reinvention of the wheel, without any benefits. Yes, there is the obvious language difference (C compared to C++), but one has to bear in mind that the entire GObject approach is basically a reinvention of C++ objects.

The poorness (on several levels) of GTK reminds me of the many arguments hashed out during the Debian "discussion" about selecting systemd over upstart. In this case GTK is the technically inferior solution.


(Log in to post comments)

Clasen: Introducing GtkInspector

Posted May 17, 2014 6:07 UTC (Sat) by donbarry (guest, #10485) [Link]

Unlike systemd/upstart where an individual system can realistically have only one init system, and there are good reasons for a distribution to architect around a preferred one in common with others -- graphical toolkits can easily exist in parallel.

Both Qt and Gtk have large communities and many applications built upon them. Gtk, we must recall, achieved early prominence because of the then troubled licensing situation of Qt. In fact, the success of Gtk can very arguably be said to have led to the favorable licensing situation of Qt today.

Today we are lucky to have two strong toolkits with different styles and approaches. That is not a bad thing. There is no "reinvention" of the wheel here: these are two styles of wheels with long histories for each.

Even if we presume for the sake of argument that Qt is now technically superior, what are you advocating -- the obliteration of Gtk? That would result in untold pain to other developers who made the choice of that toolkit, whether recently or a decade ago. It would result in the bitrot of old applications without current developers. Everyone loses.

I extend, rather, my sincere thanks to both Gtk and Qt developers for the wonderful tools you have created that play such a key role in so very many useful applications which I run on a daily basis.

Clasen: Introducing GtkInspector

Posted May 17, 2014 17:52 UTC (Sat) by raven667 (subscriber, #5198) [Link]

Not obliteration but promotion of one toolkit as the primary default with other toolkits which are used for legacy, unmaintained software or experimentation as secondary. I for one would like to see the GNOME project create some of their utilities using Qt just to take it out for a spin and to get some skin in the Qt game. Supporting Qt as a first-class citizen on the GNOME desktop, by using it, would do a lot to end the idea that you have to pick a camp in the Linux desktop wars and get siloed into this bifurcated technology universe. Maybe this would be the beginning of a "Linux standard desktop" where there is a default technology stack you can rely on, rather than two competing stacks which share only a few components.

I think that you are right in that the creation of Gtk in competition to Qt helped greatly in getting Qt where it is today in terms of technology and license, but now that we've all won it may be time to stop competing and start working together and if one of these projects is going to become legacy, it should probably be Gtk, the Qt stack seems to have consistently more resources maintaining it, and more shipping software using it. From my leather armchair smoking a cigar and sipping bourbon it seems like the winner. 8-)

Clasen: Introducing GtkInspector

Posted May 17, 2014 19:19 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

I might agree with you except that Qt still requires you to a sign a CLA to contribute. If the assets were controlled by a non-profit foundation with commercial support by multiple vendors, that would be a more natural alignment with GNOME.

Clasen: Introducing GtkInspector

Posted May 17, 2014 19:23 UTC (Sat) by raven667 (subscriber, #5198) [Link]

That's a good point. I still think that direct participation in the Qt ecosystem, which would require using it and developing it, would give more leverage to make these kinds of changes, as you go from being one of "them" to one of "us".

Clasen: Introducing GtkInspector

Posted May 17, 2014 21:31 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Not necessarily. c.f Suse, Sun and OpenOffice.org. I don't recall any counter examples.

Clasen: Introducing GtkInspector

Posted May 18, 2014 15:57 UTC (Sun) by raven667 (subscriber, #5198) [Link]

That's another good point. Even in that case though the effort wasn't split across two unrelated code bases so even though the community split they were still able to take advantage of their pooled efforts. I think LibreOffice still has more man-hours of effort put into it than AbiWord and Gnumeric for example, how much time and how many people who are working on something does make a difference in quality and features.

Clasen: Introducing GtkInspector

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

Now consider this: If Suse and Red Hat had invested in OpenOffice.org but one that wasn't burdened by Sun's restrictions, all the energy we see around libreoffice.org, we might have seen a decade back. Governance matters to any large open source project and one that is frequently overlooked till there is substantial damage already done. This isn't limited to legal restrictions (Ex: Xfree86) but one important piece is whether the governance model, allows multiple commercial vendors to participate without ceding control to one company. Projects that are neutral (Linux Kernel, OpenStack) generally do much better than projects that don't (Hudson) in attracting such contributions. There are some limited exceptions (OpenJDK is not doing too bad despite Oracle's lawsuits) but in almost all such cases, having a non-profit foundation at the center helps.

Clasen: Introducing GtkInspector

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

Qt's Open Governance is working quite well. The restrictions due to CLA aren't that bad, nothing like OpenOffice or MySQL, as you like to compare to. More like how it is here at ownCloud - I haven't met a single person who has had a problem with our CLA and our business model.

Qt, unlike GTK, also has a very healthy ecosystem with a wide variety of companies contributing and offering consulting - about 40% of contributions comes from other companies and individuals (see http://www.macieira.org/blog/qt-stats/ ) and that alone is far more than GTK gets in total.

I would count the ecosystem argument as a pro for Qt, not GTK. And so do others, considering the contributions and projects moving over to Qt ;-)

Not that I don't think a non-profit could improve things at some point, but with the protection from the KDEFreeQtFoundation and the business alignment and relationships between Digia and the other partners in the ecosystem, things are quite secure.

Clasen: Introducing GtkInspector

Posted May 19, 2014 13:31 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

I have a problem with any CLA that given a unequal advantage to a single commercial player and if Digia and OwnCloud does that, it is as bad as any other CLA out there and things might look secure for now but I don't trust that sort of model anymore and a non-profit foundation is a way to preserve that neutrality without the need to look at one company's financial statements which might not even be public since these are private companies.

Clasen: Introducing GtkInspector

Posted May 19, 2014 13:37 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

It turns out to be the case that Digia plc is listed on the Helsinki Stock Exchange.

Clasen: Introducing GtkInspector

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

Yes, you have every right to not want a CLA in place. But as I argued below, the CLA doesn't take anything away from the ecosystem. There isn't a single business model limited by one company in the ecosystem having a CLA agreement - the code is LGPL.

That is, as long as development is under a proper open governance and you have a guarantee that the product stays open. And it is. So while you can be against it for personal reasons, there is no objective downside to it.

And yeah, Digia is a public company.

Clasen: Introducing GtkInspector

Posted May 19, 2014 20:38 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

> But as I argued below, the CLA doesn't take anything away from the ecosystem.

Sure it does. You have a single entity who's able to compete in ways that nobody else can. If I write a significant body of work based on Qt then my choices are either (a) sign the CLA, giving Digia a significant competitive advantage over me when it comes to selling my code to other companies who want to ship proprietary forks of Qt, or (b) not signing the CLA, ensuring that most of the ecosystem never gets to use it. In the absence of any incentive to pick (a), the ecosystem suffers.

Clasen: Introducing GtkInspector

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

Yes, in a CLA ecosystem, one party can do something which in a non-CLA ecosystem, simply NOBODY can. That means that unless you're that one company, your options are the same as in a non-CLA ecosystem. For you, nothing is different.

Oh, wait, somebody has an unfair advantage. That is how they pay for all the Qt developers to work on the toolkit, which we all benefit from. Including you. Bigger pie beats fighting over the pie, if you ask me.

The result is a toolkit that has hundreds of paid developers. If you prefer to fade into nothingness because you don't have the resources to build a first-class toolkit that's fine. At least nobody has a competitive advantage over you! not that there's any market to fight over left...

Really, I'm not a huge CLA fan myself, but if it is done properly and reasonably, it simply works. And I care more for actually bringing FOSS to people than some barely relevant "I don't like the unfair advantage" thing.

Pragmatism, baby.

Clasen: Introducing GtkInspector

Posted May 19, 2014 22:07 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

It means Digia can pay for Qt developers. It means nobody else is as likely to. You may feel that this is the optimal situation for the ecosystem, but don't pretend that there are no downsides. Other projects manage to support commercial development without CLAs, so it's clearly not impossible. It's just not the business model that Digia have chosen.

Clasen: Introducing GtkInspector

Posted May 19, 2014 22:15 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> It means nobody else is as likely to.

To elaborate on this point in case it isn't clear, many businesses won't have their paid developers work on code to then sign over the rights with a CLA to another company, so you are likely to only get contributions from unpaid volunteers, who can't help work on the code full-time like paid developers from other companies can. To put a finer point on it, the commercial Linux distributers and consultancies are unlikely to put any full-time paid development resources into a CLAd community for this reason alone.

Clasen: Introducing GtkInspector

Posted May 20, 2014 2:27 UTC (Tue) by torquay (guest, #92428) [Link]

Yes, one would think that this would generally true, but the GUI toolkit situation under Linux shows that a different set of dynamics and realities is at work.

Specifically, the amount of paid contributors to GTK is tiny (mainly Gnome folks from Red Hat), and pales in comparison to the large number of unpaid volunteers contributing code to QT. What's more, QT also has paid developers (Digia), which outnumber the unpaid volunteers. The end result is that GTK is developer starved, while QT is a well funded professional effort.

Having a CLA allows Digia to create a stable environment for developers, which ends up being a virtuous circle. The better QT gets, the more money Digia brings in, which pays for the developers and brings in more volunteers. QT is still open source, with a guarantee of always being open source.

This all goes to show that there is more than one business model for creating, maintaining and profiting from open source software. Having a non-profit foundation is certainly one way, but not the only way.

Red Hat brings in money through subscriptions, and enforces this through asserting and defending its trade marks. We're not complaining about how Red Hat is paying people to develop open source software, and neither should we be complaining about how Digia is paying people to develop open source software. They obtain their money in different ways, but the end result is more open source software.

Clasen: Introducing GtkInspector

Posted May 20, 2014 3:35 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

"We're not complaining about how Red Hat is paying people to develop open source software, and neither should we be complaining about how Digia is paying people to develop open source software. They obtain their money in different ways, but the end result is more open source software."

Who is we? Didn't you start the thread on a news post about a new GTK development with your opinions on how development of GTK itself is pointless and has no benefits compared to Qt. If you are going to characterize the replies pointing out the benefits of GTK in comparison to Qt as complaints, that applies equally if not more to your original post. So heed your own advice.

Clasen: Introducing GtkInspector

Posted May 20, 2014 7:26 UTC (Tue) by jospoortvliet (subscriber, #33164) [Link]

That seems quite a different thing - he said GTK offers nothing over Qt. I agree that Free Software would be better off if projects moved to Qt, just like we let FLTK die in peace. You brought up that you don't like the business model of one of the contributors to Qt and I said that at least it WORKS and it seems quite irrelevant in the big picture...

Clasen: Introducing GtkInspector

Posted May 20, 2014 14:01 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

" That seems quite a different thing - he said GTK offers nothing over Qt. I agree that Free Software would be better off if projects moved to Qt, just like we let FLTK die in peace"

Wishing that alternatives to your favorite toolkit just die doesn't seem to be the right mindset. I don't see such posts on news regarding new Qt features.

". You brought up that you don't like the business model of one of the contributors to Qt and I said that at least it WORKS and it seems quite irrelevant in the big picture..."

Now you are downplaying the issue. Qt trademark and copyrights are aligned with one company that controls it via a CLA. So it is not merely a business model of just one company and it isn't the company that matters as much as the problems associated with the CLA based development model. We all I think agree that there are problems but we might have different perspectives on the impact in this case which is fine but it certainly isn't irrelevant especially when you consider the big picture.

Clasen: Introducing GtkInspector

Posted May 20, 2014 14:04 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> Wishing that alternatives to your favorite toolkit just die doesn't seem to be the right mindset.
Having multiple GUI toolkits is actively harmful, and given that Qt beats the pants off GTK in almost every way, it's clearly GTK that needs to go away.

Clasen: Introducing GtkInspector

Posted May 20, 2014 14:51 UTC (Tue) by raven667 (subscriber, #5198) [Link]

That is hyperbolic, to the point of absurdity, as is often the case. There is no inherent harm in having some specialty toolkits if people want to work on them but that doesn't mean there shouldn't be a standard default toolkit that is relied upon as part of the basic API of any desktop, that all desktop environments should be able to consider native and not foreign even if the desktop compositor itself does its own thing.

Clasen: Introducing GtkInspector

Posted May 20, 2014 16:22 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> There is no inherent harm in having some specialty toolkits if people want to work on them
There is. Having two completely separate toolkits means I can't use custom widgets developed for GTK in my Qt application or vice versa. It means that many applications will look inconsistent on my desktop. It means that tools such as graphical GUI builders cannot be shared. And there are many, many more problems caused by this...

Clasen: Introducing GtkInspector

Posted May 20, 2014 16:26 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I can't stick a whole banana in my ear either but I'm not claiming this failure is inherently harmful.

Clasen: Introducing GtkInspector

Posted May 20, 2014 18:39 UTC (Tue) by HelloWorld (guest, #56129) [Link]

That comparison is so lame it needs a wheelchair.

Clasen: Introducing GtkInspector

Posted May 20, 2014 18:43 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

I can't cut and paste python into my C code either. We seem to cope.

Clasen: Introducing GtkInspector

Posted May 20, 2014 19:05 UTC (Tue) by HelloWorld (guest, #56129) [Link]

We can call C from Python and vice versa. How do I embed a GTK widget in a Qt application?

Clasen: Introducing GtkInspector

Posted May 20, 2014 19:13 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Conceptually: in Qt, implement a GtkDrawable with a QPainter to draw on and in GTK, implement a QPainter with a GtkDrawable in it and add Qt widgets to the QPainter. Or something like that. Size hint and event translation is likely going to be the killer though.

Clasen: Introducing GtkInspector

Posted May 20, 2014 20:08 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Has anybody ever actually done this and used it productively? Is it documented?

Clasen: Introducing GtkInspector

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

And Qt has paid developers in other companies -- like KDAB.

Clasen: Introducing GtkInspector

Posted May 20, 2014 15:07 UTC (Tue) by raven667 (subscriber, #5198) [Link]

That's great but I think the original point wasn't to list all the companies which are deeply in the Qt ecosystem and support Digia, it was to point out the companies which have no-CLA policies, that this is a real thing which is blocking some areas where Qt could grow into. Is the point to say f**k-em if they don't like a CLA and bifurcate the marketplace or to try and grow and incorporate all the parties because there are influential members of the larger Linux community that won't participate under those terms.

I don't think any proprietary-CLA'd software can take a place as a standard component on Linux because of this, but maybe I'm wrong. It doesn't seem to be working out for Canonical though...

Clasen: Introducing GtkInspector

Posted May 21, 2014 3:31 UTC (Wed) by torquay (guest, #92428) [Link]

    I don't think any proprietary-CLA'd software can take a place as a standard component on Linux because of this

QT is open source, not proprietary. Also, QT is already a standard component in Linux-based OSes, via the LSB. It's also in Fedora, Debian, Ubuntu, etc since forever.

This entire ideological aversion to CLA'd software is bordering on insane. The software is still open source, which is of primary importance, not secondary. Using GTK when there is a known and significantly better alternative is cutting off one's nose to spite the face (ie. self destructive). By choosing GTK, a developer in effect cuts themselves off from a considerably more vibrant development community, a better maintained toolkit, more stability, saner use, better documentation, etc etc.

You can't chage reality: GTK, despite the lack of a CLA, is in a much worse state than QT, whose main developer (Digia) has a CLA. The onus is hence on the anti-CLA brigade to practically demonstrate (not just theoretical mumbo jumbo) that CLA is actively harmful in this case. The evidence is pointing in the other direction: CLA is actually very useful in this case.

Clasen: Introducing GtkInspector

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

> QT is open source, not proprietary.

But the point is that with a CLA it can be taken proprietary at any time, that's the whole point of having one.

> You can't chage reality: GTK, despite the lack of a CLA, is in a much worse state than QT, whose main developer (Digia) has a CLA. The onus is hence on the anti-CLA brigade to practically demonstrate (not just theoretical mumbo jumbo) that CLA is actively harmful in this case. The evidence is pointing in the other direction: CLA is actually very useful in this case.

That seems like a claim that software, without a gatekeeper company with a CLA selling proprietary versions, can't be successful. That is a different discussion. The point I've been trying to make, that I haven't seen acknowledged, is that, even given the number of contributors to Qt, there are an even wider array of potential contributors who abstain because of the CLA, and even provide roadblocks preventing Qt from achieving the market dominance it may be capable of, by funding competing projects.

Look at the recent sweep of systemd across the major distributions, if it was CLAd to RedHat do you think it still would have been successful? It was successful because the project did the hard work of adjusting to the needs of all the participants, supporting Debian and SuSE-isms when needed, instead of claiming they were doing it wrong and that their contributions weren't welcome.

Clasen: Introducing GtkInspector

Posted May 21, 2014 14:53 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> But the point is that with a CLA it can be taken proprietary at any time, that's the whole point of having one.

And if that happens, the KDE Free Qt contract triggers and we get a BSD release of the last non-proprietary Qt release. Where do you think companies would go then?

Clasen: Introducing GtkInspector

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

That is an interesting question, I'm not sure there is a general answer, it might be very situation dependent. If the proprietary fork takes the bulk of the senior, full-time development staff with it then any ISV which is depending on Qt has to decide whether they take ownership of the whole toolkit, switch to something else or suck it up and buy proprietary licenses. This will split the community as different projects will make different decisions. The different versions may become incompatible with one another, the Free version may just bitrot over time.

If the core developers do leave then they might form another company or disperse into other companies and continue to work on a fully-functional, Free toolkit. If one group or the other can't recruit a critical mass of developers then maybe all available versions bitrot or go on life support with a slow trajectory of features and fixes.

Maybe the worst case is if the development community splits into multiple proprietary forks, since with BSD license there is no enforcement of a software commons to collect contributions, then they probably all die over time, failing to achieve a critical mass of developers or customers, with features maybe folding in when individual forks go belly-up, or being lost.

Almost any scenario I can think of involves there being less developers working on any particular fork so as a consequence development must slow down (or stop), compared to a non-forked scenario, and upheaval for anyone who has a core dependency on the toolkit. It's probably a stronger dependency and harder to switch than MySQL/MariaDB to PostgreSQL for example.

If you are lucky then if there is a fork like this the bulk of the developers go to the Free software version, which then supplants the proprietary fork and becomes standard like LibreOffice vs. StarOffice, but you can't always rely on being lucky.

Clasen: Introducing GtkInspector

Posted May 22, 2014 8:20 UTC (Thu) by niner (subscriber, #26151) [Link]

The point still is: Qt does have more independent contributors than Gtk has in total! So you're arguing that people should choose a toolkit that is barely maintained by few developers because the in almost any sense superior alternative might in theory at some time in the future have fewer contributors than it has now. And this does not make any sense at all.

The Gtk developers may loose interest in their toolkit anytime as well. Same as they have already lost interest in really supporting non-Gnome applications and other operating systems than Linux.

I agree that the optimal situation would be to have a CLA-free Qt. But that's right now not an option. Even with the CLA Qt has better technology, better documentation, better maintenance, more independent contributors and more contributors overall. The choice is pretty much obvious.

Clasen: Introducing GtkInspector

Posted May 22, 2014 15:31 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I clearly have not been clear, I am not advocating for GTK or arguing that people should choose it, quite the opposite in fact, but I am pointing out the fact that there are various reasons some are choosing GTK and that he CLA is one of those reasons so if you want to pick up those users/organizations which are currently backing GTK the CLA is one reason why this hasn't happened.

Clasen: Introducing GtkInspector

Posted May 22, 2014 17:31 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

Which organizations? Who is choosing to port to GTK or start a new project in GTK because of Qt's CLA?

Clasen: Introducing GtkInspector

Posted May 22, 2014 8:43 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

See, and that is where an ecosystem is important. If all the senior contributors to a project would work for a single company, this would be a risk.

Reality is different, again: 40% of contributions to Qt come from outside of Digia. Which, as was pointed out before, on its own already represents more contributions than GTK gets as a whole - making a Qt-without-Digia still a healthier ecosystem than GTK ever will be.

Sorry, but this is frustrating. You and Rashul are arguing that due to a hypothetical and unlikely risk, which if taken place would still put Qt far ahead of GTK, we should not rely on Qt. You argue that the CLA has all kinds of horrible effects (resulting in 'nobody else would want to contribute to it') while the current reality CLEARLY proves you wrong, I can keep quoting it: about 40% of the code in Qt comes from outside of Digia. That number makes all these hypothetical anti-CLA arguments moot. There is a huge business around Qt and I can so name you three independent parties which would be able to maintain Qt all on their own if all Digia offices would be simultaneously hit by a meteor tonight (or tomorrow, rather, there's a great shower coming, you're lucky if you're in the US. Watch it around 3PM Eastern time and tell me what a sucker I am for living in Berlin).

If Digia hadn't bought Qt from Nokia, don't you think KDE, KDAB and the many other companies and communities building on top of it would've set up a foundation and kept the LGPL version alive? There are 500.000 developers using Qt out there. If only 5% of those gave a crap that Qt would go proprietary, the project would have orders of magnitude more resources than GTK.

I have a feeling you're still stuck in the unclear Qt licensing situation in the end of the 90's. But things have changed. Qt is a hugely successful open project now, GTK can't even see the tail lights anymore. KDE is splitting up its libraries, having upstreamed half to Qt and making the other half available as independent parts to Qt developers, hoping to ride the wave of Qt success.

Meanwhile, today, GTK just makes Linux look bad.

This is NOT against GNOME: GNOME SHELL doesn't make Linux look bad, not by a long shot. I don't use it, it isn't for me, but that does not mean I don't recognize that it is a great looker, exploring new interaction patterns, building innovative interfaces. I appreciate and applaud that. Of course I can't for the love of $DEITY imagine why that requires a custom-build toolkit, but fine. Just stop telling the rest of the world to build anything on Shell or that toolkit, really, it is a BAD IDEA.

Clasen: Introducing GtkInspector

Posted May 22, 2014 15:48 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> Reality is different, again: 40% of contributions to Qt come from outside of Digia.

This is not a point that I am talking about, I agree that the Qt ecosystem has a lot of developers. Clearly I haven't been able to communicate what hair I am splitting here. The point is that there clearly exists an ecosystem around GTK who haven't chosen to use Qt and that if you want to convert those users and bring them into the Qt ecosystem then you will have to find out what their concerns are which are preventing them from joining and address them. One of those concerns seems to be the CLA. Talking about how big the Qt ecosystem currently is and how successful it has been doesn't change the fact that there is another (smaller) ecosystem out there blocking any kind of universal consensus in the Linux desktop space.

Maybe an analogy can help (or make it less clear 8-). A desktop software application which is only in English can have a large, vibrant development and user community and be wildly successful, but there will always be a part of the marketplace where telling potential users/developers to "learn English" is not going to be helpful, so there will always be a percentage of the marketplace you are cutting out by that decision.

Clasen: Introducing GtkInspector

Posted May 22, 2014 18:46 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> The point is that there clearly exists an ecosystem around GTK who haven't chosen to use Qt and that if you want to convert those users and bring them into the Qt ecosystem then you will have to find out what their concerns are which are preventing them from joining and address them.
I doubt that the CLA is one of the reasons. There are nowadays two reasons people pick GTK: Gnome and legacy code. Addressing those is close to impossible for the Qt developers.

Clasen: Introducing GtkInspector

Posted May 22, 2014 20:09 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

"I doubt that the CLA is one of the reasons. There are nowadays two reasons people pick GTK: Gnome and legacy code. Addressing those is close to impossible for the Qt developers."

Actually, is there any recently started project that picked GTK? Any project that felt, "Yo! users are in need of XYZ, let's give it them asap, so, the obvious choice is to start coding it in C and GTK!"?

Or even, "Yo! We're not giving our users what they need, we're not making progress as quick as we could, let's port to GTK, yay!"?

Clasen: Introducing GtkInspector

Posted May 22, 2014 20:37 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Uzbl is pretty small, but WebKitGTK just provides lots more access than QtWebKit, so we're stuck with GTK. I was looking forward to WebKitNix (an OpenGL port), but that has died off already :/ .

Clasen: Introducing GtkInspector

Posted May 31, 2014 14:36 UTC (Sat) by Velmont (guest, #46433) [Link]

Question, have you looked into Chromium at the content API layer? There's quite some compartmentalization going on, and making the project more useful for outsiders.
We're even doing some of that work in Opera (where I work), because it's obviously helpful for us :)

Clasen: Introducing GtkInspector

Posted May 26, 2014 15:00 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

But the point is that with a CLA it can be taken proprietary at any time, that's the whole point of having one.

... and this piece of nonsense keeps irking me every time I read it. What crazy business model would that be, developing something for years in the open just so you can, some day, suddenly (after a super special code commit or something) close it up?

You don't seem to get the business model of companies like Qt (and others). Some of their customers' legal departments insists on not having any (l/a)GPL software. Fine, they pay for that 'privilege', that helps keep Digia paying hundreds of people to work on that software. But they do not, ever, intend to stop developing in the open. Why would they abandon a successful, smart business model where they work with a wide community of contributors to build great software? Again, Qt - 40% contributions outside of Digia. How stupid does one have to be to loose that?

I totally get that there is a fear that a potential, future owner would do that. Eg a Oracle that buys Qt. But THAT is exactly where the KDE Free Qt Foundation comes in so that risk is mitigated. And it could still be a realistic fear if this was throw-over-the-wall open source, like Android. But it isn't - Qt is developed fully in the open. Quite some sections are now maintained by people outside of Digia - Digia engineers have to engage these community members to get their code into Qt. Just as it should be.

You're just spreading FUD with this. And I'm quite sure you're aware of that, too, I'm sure I didn't tell you anything new.

Clasen: Introducing GtkInspector

Posted May 20, 2014 7:29 UTC (Tue) by jospoortvliet (subscriber, #33164) [Link]

I'm not saying there are no downsides, but you are sure wrong about businesses not paying developers to contribute code to Qt despite the CLA.

There is more paid Qt contributions outside of Digia than all of GTK (free and paid) combined - so reality renders your argument moot.

Clasen: Introducing GtkInspector

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

    I might agree with you except that Qt still requires you to a sign a CLA to contribute. If the assets were controlled by a non-profit foundation with commercial support by multiple vendors, that would be a more natural alignment with GNOME.

I don't disagree that having a foundation + backing by multiple commercial vendors would be better. This certainly works for the Linux kernel and gcc. However, given that there is far less interest in desktop technologies on Linux (not counting Google's Chromebook), we have far less interested commercial parties to provide associated backing. The reality is that there is only one company: Digia. In contrast to the amount of effort put in by Diga into QT, the amount of effort put in by Red Hat into GTK and Gnome is miniscule. Canonical, with its Unity/Mir efforts within Ubuntu is quite likely a rounding error in contrast to QT.

An idealogical stance along the lines of "must have more than one commercial backer before we use it" does not square with the reality of the present situation. Having one commercial backer for an open-source project is better than no backers. Having any commercial backer is also a rare luxury: the vast majority of open source projects is run entirely by volunteers.

Clasen: Introducing GtkInspector

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

Digia is not the only organization interested in desktop toolkit development but setting side that, the key part is not multiple commercial vendors. That will happen organically if the governance is setup to encourage that and there is enough industry interest to do it. The more relevant part is that assets such as copyrights (via CLA) and trademarks shouldn't be controlled by a single commercial organization in a major open source project that we all rely on. We have learned repeatedly what happens when we choose to overlook this (ex, OpenOffice.org, Hudson etc etc). I don't consider this ideology. Just prudent risk management. Digia is welcome to setup a non-profit foundation or work with an existing foundation like SFC and drop the CLA. Until that point, it is far from a clear win and GTK is the best alternative that the community has.

Clasen: Introducing GtkInspector

Posted May 18, 2014 8:34 UTC (Sun) by niner (subscriber, #26151) [Link]

It would be, if it weren't for the KDE Free Qt Foundation: http://www.kde.org/community/whatiskde/kdefreeqtfoundatio...

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

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.

Clasen: Introducing GtkInspector

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

Luckily, it isn't as bad as Torquay thinks: Digia is by far not the only contributor to Qt. The largest, yes, but not the only. About 40% of code comes from the outside, which, for a project that opened up less than 5 years ago, is quite good.

Clasen: Introducing GtkInspector

Posted May 18, 2014 22:05 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> Today we are lucky to have two strong toolkits with different styles and approaches. That is not a bad thing. There is no "reinvention" of the wheel here: these are two styles of wheels with long histories for each.
It is in fact a *very* bad thing. When I write an application and somebody has written a GTK widget I'd like to use and somebody else has written a Qt widget that I'd also like to use, I'm fucked, I can't really use them together. It also affects users as Gtk applications don't integrate properly with a KDE Desktop. And there's literally dozens of programs whose only reason for existing is “it's like this other program but it uses Gtk instead of Qt” (or vice versa).

Maybe having different desktops for different users is a useful thing to have. But different toolkits? No, that's nonsense.

Clasen: Introducing GtkInspector

Posted May 17, 2014 8:40 UTC (Sat) by ballombe (subscriber, #9523) [Link]

So what is the equivalent of editres/gtkinspector for Qt ?

Clasen: Introducing GtkInspector

Posted May 17, 2014 9:24 UTC (Sat) by richmoore (guest, #53133) [Link]

> So what is the equivalent of editres/gtkinspector for Qt ?

The best equivalent is gammaray https://www.kdab.com/kdab-products/gammaray/

Clasen: Introducing GtkInspector

Posted May 17, 2014 16:28 UTC (Sat) by rsidd (subscriber, #2582) [Link]

I think the parent is seriously OT and perhaps a troll. But here is one point of GTK: there is plenty of software already existing that uses GTK, some of which is heavily used by nearly every Linux user; it would be expensive to migrate all of it to Qt, even if it were desirable, which not everyone would agree with; therefore it is desirable to develop GTK just to have the side-effect of improving that software.

But of course that's not the major reason. The major reason is that some people like hacking on / using GTK.

Maybe, if some Qt advocate would write a GTK-compatible library that called Qt for heavy lifting and mainly provided wrapper functions for GTK programs (if Qt is so awesome it should be easy to do this, right?) GTK will die after that...

Clasen: Introducing GtkInspector

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

Yeah, GTK2 isn't going away anytime soon. But instead of porting to the always-moving-GTK3, some are going for Qt. LXDE wrote a great how-to for porting to Qt: http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt and I know KDAB and some other consulting companies in the Qt ecosystem have plenty of experience with it as well.

Clasen: Introducing GtkInspector

Posted May 17, 2014 21:00 UTC (Sat) by tuna (guest, #44480) [Link]

Nice links. So according to Hohndel's talk, if you get core QT devs to write your UI layer QT can do more stuff than GTK. Also, the LXDE link does not discuss any reasons for moving to QT from GTK (or vice versa) only differences in GTK's C (native) API vs QT's C++ (native) API.

Clasen: Introducing GtkInspector

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

My bad. There are several reasons for LXDE moving away from GTK to QT. The wikipedia article on LXDE provides a rough summary.

In essence, GTK2 was deprecated and LXDE developers realized that they had to port their stuff to GTK3. If such porting was necessary, other toolkits should be looked at as well. In early 2013, the main LXDE developer stated "I must admit that working with Qt is quite pleasant". A little later, another blog post states:

    I, however, need to admit that working with Qt/C++ is much more pleasant and productive than messing with C/GObject/GTK+. Since GTK+ 3 breaks backward compatibility a lot and it becomes more memory hungry and slower, I don’t see much advantage of GTK+ now. GTK+ 2 is lighter, but it’s no longer true for GTK+ 3. Ironically, fixing all of the broken compatibility is even harder than porting to Qt in some cases (PCManFM IMO is one of them). So If someone is starting a whole new project and is thinking about what GUI toolkit to use, personally I might recommend Qt if you’re not targeting Gnome 3.

    (...)

    Don’t get me wrong. I’m not saying that gtk+ is bad and did not intend to start a toolkit flame war. If you’re going to use python, C#, or other scripting language, gtk+ is still a good choice due to its mature language bindings. Vala is attractive initially, but after trying it in real development, you’ll see the shortcomings of this approach. Because it sometimes generates incorrect C code that still compiles, we got some really hard-to-find bugs. So we need to examine the generated C code to make sure it does things right. This takes much more time than just writing plain C code myself. Besides, the generated C code is not quite human-readable and debugging becomes a problem. Another issue that’ll hit you is the problems in the library bindings. Though there exists many vala bindings for various C library, their quality is uncertain. Finally, debugging, examing, and fixing the bindings all the time takes even more time and offsets the time saved by using Vala. To sum up, for compiled binary programs, Qt IMHO is a good choice to consider if you don’t hate C++.

Around the same time the Razor-QT project sprung up. Its goal was to provide a desktop environment based on QT technologies, but without the bloatedness and overhead of KDE. As LXDE and Razor-QT had similar goals, and LXDE was making progress in porting to QT, the LXDE and Razor-QT projects merged to avoid duplication of effort.

Recently (early May 2014), the combined projects made an initial release of the merged LXQt desktop. A follow-up post provides a bit more info on the differences between GTK and QT, as well as a plot from Google Trends that shows GTK declining in popularity.

Clasen: Introducing GtkInspector

Posted May 18, 2014 8:13 UTC (Sun) by Seegras (guest, #20463) [Link]

> So what is exactly the point of GTK,

Yes, C. I don't program C++, so it's nice to have a toolkit in C.

Clasen: Introducing GtkInspector

Posted May 18, 2014 13:15 UTC (Sun) by rleigh (guest, #14622) [Link]

That's a mistaken assumption though. GTK+ is not really "C", it's "GObject-based C", which is fundamentally different. The problem with this is that even if you're an expert C programmer, GTK+ is still a worse choice than Qt. It will take less time and effort to learn and master C++ and Qt than it will to learn and master GTK+, and your code will be of higher quality to boot.

The thing is, if you're writing anything other than a trivial example, using GTK+ requires using GObject/GType, and this means that you will be:

- doing RTTI in C
- constructing virtual call tables by hand
- writing constructors and destructors by hand (not just the easy bits either, but all the extra stuff C++ does for you, plus you have to handle the multi-phase construction and destruction GObject performs, which is vastly more complex than C++)
- you'll be forced to use construction properties which are not efficient
- writing all the type initialisation and registration code to register your classes with GType
- generating all the cast macros
- doing all the refcounting by hand
- you'll need to know more about C++ implementation details than most C++ programmers in order to understand and use it

This "works", don't get me wrong. But... the level of expertise and proficiency required to do this is beyond silly. It requires the user to replicate, by hand, in C, complex implementation details which would be automatically generated by the C++ compiler, like vtables and typeinfos and marshalling. And all the RTTI stuff. At this point, you really have to question whether the "benefits of C/GObject" are worth the cost:

- It's more complex than C++
- It's more fragile than C++
- It's more difficult to maintain and refactor than C++
- It's slower
- Type bugs are often not found by the compiler because you cast away the type information; this is worked around by runtime checks but even these can fail to work properly, and have a cost since they are done for every method call.
- Memory leaks are common because you're doing all the refcounting by hand

If you wanted to start a new project and had to make the choice between C++ (which is well understood by many) or GObject/GType (which is not, and for good reason because it's awful) there isn't really a choice here at all. I used to be a C zealot who went through the pain of using GObject for OO-C even for non-GTK stuff; but I was deluding myself. C is not the best tool for every job, and it's not good at OO even if it's "technically possible". It's not the best tool for the job, not by a long shot. I ported it all to C++ years back, and found bugs while doing so which hadn't been picked up while using GObject. That is to say, converting it to conventional C++ code improved its quality significantly, and the bugs that I fixed would would not have been found while I continued to use GObject--they were hidden. And once converted to C++, refactoring and adding new functionality became simple; it was a significant burden with C/GObject and it was too easy to introduce subtle bugs since the compiler won't pick up the bugs for you.

Now, the harsh reality is that vala, the language bindings etc. are all various attempts to paper over these unfortunate fundamental shortcomings, while failing to actually address them. Some of them get close, but ultimately it's still built on the same very poor foundations. And you always run into bugs in the bindings, so if you want to do stuff properly you still have to do it in C.

Imagine a commercial project where you need to pitch this to your management for a new project. It's unlikely that GTK+/GObject could be chosen over C++--it would be a risky and irrational choice to make in the face of its many serious shortcomings. (I have done this in the past, before Qt was fully free; we went with GTKmm and still ran into many problems. Lately when evaluating cross-platform toolkits for new projects, Qt and PyQt are at the top of the list and GTK+ isn't even on the list, I'm sad to say.) Hiring or training staff to work on it would be difficult as well; the pool of C++ programmers who already know or could easily pick up Qt is vastly greater than the small number of masochists willing inflict GObject upon themselves (as I once did). It's not like it's even well documented, it's an exercise in pain and frustration. In comparison, the Qt documentation is pretty good.

GTK+ is, and was, driven primarily by "C zealots" (as I once was) who are prepared to use C for everything, come what may. Unfortunately, the reality for the rest of the world is that this is an unsuitable foundation for serious projects. Using GObject requires sacrificing code quality, maintainability and performance, and for most that's not acceptable since it doesn't provide any benefit, other than avoiding C++. It's not benefiting the project themselves.

Regards,
Roger

Clasen: Introducing GtkInspector

Posted May 18, 2014 16:56 UTC (Sun) by nybble41 (subscriber, #55106) [Link]

As I see it, the problem isn't so much wanting to write programs in C as wanting to to write them in other languages which have good foreign-function interface bindings to C, but not to C++, because *nothing* has good FFI bindings to C++. Calling C functions from Ruby, Java, Haskell, or just about any other language with an FFI is trivial. Binding to C++, with its overloading, templates, etc., is not. Accessing C++ libraries like Qt generally comes down to duplicating the entire public API in C and hoping that you can get by without templates or subclassing.

Exposing a C API for your library isn't just about letting people code in C, it's about letting them code in the language of their choice, most of which (including C++) have C FFIs. If your API is in C++ then using it from any other language will be far more difficult.

Clasen: Introducing GtkInspector

Posted May 18, 2014 19:23 UTC (Sun) by boudewijn (subscriber, #14185) [Link]

In practice, all the perpetual claims how it's so much nicer to create bindings to a C library than it's to a C++ are moot.

In the real world, PyQt and Pyside are perfectly fine to build huge, complicated and succesful applications with.

And that's what counts.

All the rest is bunk.

Clasen: Introducing GtkInspector

Posted May 18, 2014 20:33 UTC (Sun) by rleigh (guest, #14622) [Link]

Technologies like sip (PyQt) and Boost.Python seem quite capable of generating perfectly usable C++ bindings for Python, for example. In fact, with Boost.Python you can write a Qt application that uses python internally which can itself use PyQt to embed in the main UI. (This is currently on my TODO list to trial.)

The number of language bindings has long been touted as a good reason for sticking with C. However, while this might be true in theory, in practice how many of the GTK+ bindings are currently complete and usable? Last time I looked, a number were unmaintained/outdated/incomplete, and a number were only available for GTK+ 2.x and not 3.x. I've not looked recently, but this has been true for most of the life of GTK+, so I wouldn't expect it to have changed dramatically. I've tried a few of the bindings (primarily PyGTK), and I'm afraid to say I always ran into defects (unwrapped functionality or buggy wrappers) which required me to eventually go back to C. So I'm not sure what the number of fully functional bindings is, but I wouldn't be surprised if it's just one or two in practice.

Clasen: Introducing GtkInspector

Posted May 18, 2014 21:46 UTC (Sun) by HelloWorld (guest, #56129) [Link]

GObject has become much better in that regard through GObject Introspection. In fact my impression is that Qt (and QObject-based libraries in general) could really use something like that.

Clasen: Introducing GtkInspector

Posted May 19, 2014 0:48 UTC (Mon) by sandsmark (subscriber, #62172) [Link]

I'm not sure exactly what you're referring to, but are you familiar with QMetaObject?

Clasen: Introducing GtkInspector

Posted May 19, 2014 4:03 UTC (Mon) by tetromino (subscriber, #33846) [Link]

> I'm not sure exactly what you're referring to

GObject introspection generates a description of a GObject-based API from C code comments. The result is output in the form of XML (for ease of parsing) or a binary format (for speed) and is used for automatic language bindings - currently, the main users are vala, python, and javascript. It's much more powerful than the typical ffi setup because it provides not just the C function signature but a vast amount of semantic information. The function's signature would only tell you that argument 1 is a pointer to struct foo, so is the return value, parameter 2 is an integer, and parameter 3 is a function pointer. But GObject introspection would inform you that parameter 1 is an out-parameter in the form of an array of struct foos which must be allocated by the caller (with the number of elements supplied in argument 2) and is filled in by the called function; that parameters 1 and 3 are optional and you can safely pass in NULL if you don't want them; that the return value must not be deallocated by the caller; that parameter 3 is a callback which will be called asynchronously, but only once (at which point resources associated with the callback can be freed); that the function was introduced in library version 1.2, was considered to be unstable API, had been deprecated since 1.16, and in languages which support function overloading, it makes sense to rename it to bar().

Does Qt have some equivalent of this?

Clasen: Introducing GtkInspector

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

This has been in Qt forever, from what I understand. See google:
http://stackoverflow.com/questions/19931082/implementing-...
http://woboq.com/blog/how-qt-signals-slots-work.html

And of course, the SMOKE bindings allow writing a GTK hello world app in Qt:
https://blogs.kde.org/2011/07/14/gtk-hello-world-qt-c

;-)

Clasen: Introducing GtkInspector

Posted May 19, 2014 13:19 UTC (Mon) by kigurai (subscriber, #85475) [Link]

But is there anything in place so that this information can actually be used in an automated fashion?

Currently I can start a Python shell and do

>>> from gi.repository import GtkSource

and now I can natively make calls to the GtkSourceView library using a Pythonic interface.
And the same would go for JS, or any language for which a GObject introspection functionality exists.

When I've looked at programming with Qt, I've gotten the impression that all the Python interfaces are "handcrafted" in some sense. But maybe I'm wrong on this.

Still GIR is a really nice concept that I wish was more common.

Clasen: Introducing GtkInspector

Posted May 19, 2014 13:27 UTC (Mon) by sandsmark (subscriber, #62172) [Link]

Language bindings for KDE libraries (and some other libraries, though it was made by KDE and is therefore most popular there) are made by SMOKE/smokegen automatically. It has been around for a while now. It doesn't require you to do anything at runtime though, as it seems like the GObject introspections does?

http://techbase.kde.org/Development/Languages/Smoke

Clasen: Introducing GtkInspector

Posted May 19, 2014 13:59 UTC (Mon) by kigurai (subscriber, #85475) [Link]

Hmm, I could not really make sense of the documentation of that page.
But, to met still seemed like you
1) Have to write a lot of SMOKE specific code, and
2) have to do this for every language binding?

But, as I said, the documentation was not really clear to me.

With GIR, the introspection file is created once for each library, and the GIR mechanism is created once per runtime (Python, JS, ...).
And yes, it means doing things at runtime, but I have not noticed any overhead when using the Python GIR module.
For compiled languages I am guessing you would simply call into the C-library anyway?

C more complex than C++?

Posted May 18, 2014 17:15 UTC (Sun) by riccieri (guest, #94794) [Link]

I always thought that it should be harder to make language bindings for Qt, given that it is C++, and as such it has many more features to be accounted for.

Does all that complexity around GObject/GTK tip the scale in favor of Qt?

Clasen: Introducing GtkInspector

Posted May 18, 2014 18:41 UTC (Sun) by djcb (guest, #41542) [Link]

I use both C and C++.

For the typical API-user, I've found the GLib/Gobject-based libraries of high quality (think GLib itself, GStreamer, json-glib, soup, GDBus), esp. with respect to the ease of using some of the G-niceties such as signals, watching properties for changes (or even binding them).

A hurdle comes when writing your own GObjects; that indeed requires a bit of practice - but it's not /so/ hard either -- not harder than some of the magic in 'modern' C++. There are some niceties in C++ that I miss in C sometimes -- such as some simplified memory management, and the ability to create small helper classes; perhaps lambdas. But overall, I like the clarity, simplicity of C, and I find that it's the most natural way to use the aforementioned libraries. Don't call me a 'zealot' for that!

Anyway, when we go beyond C, I hope one of the next-gen languages becomes a feasible choice (such a D or rust).

Clasen: Introducing GtkInspector

Posted May 18, 2014 21:17 UTC (Sun) by rleigh (guest, #14622) [Link]

I don't disagree with your point that these are high quality libraries. But I would qualify that with "high quality for C". When you compare their quality with C++ equivalents they are sorely lacking. Taking signals for example, the GObject-based signals are quite crude and type-unsafe. If you compare them with libsigc++ or Boost.Signals they aren't even on the same playing field. Likewise for Qt signals, though these are not quite as good due to doing method signature-checking at runtime rather than at compile-time with templates as the others do. And these libraries also allow adapters to add/remove/reorder the signal parameters and return type, so are also much more flexible as well as much more robust. Stuff like g_closure_invoke/g_cclosure_* and all the generated C marshallers are the stuff of nightmares in comparison. Today in C++ you can do stuff like using lambdas for signal handlers; it's a totally different level. (You can use libsigc++ on top of GObject with GLibmm of course, but it's still built on top of the gobject house of cards if you do that.)

Likewise, while for some writing your own GObjects might not be considered "hard", I have to disagree--it's non-obvious and fragile, and isn't properly documented. I wrote a tutorial after figuring it out which was, at the time, only the second source of information on how to do it since it was completely undocumented (http://www.codelibre.net/~rleigh/gtk/ogcalc.pdf). But the "hardness" isn't the only issue. For most people, it's robustness and maintainability. It's also not just about whether *you* can do it, it's whether all the other people on the development team get it as well, plus any future maintainers and potential collaborators. If you can do it, great, but we need to realise that this requires skills beyond what most C and even C++ programmers have--these are not learned language features, but esoteric special stuff which isn't obvious until you invest significant time to figure it all out. To get to that point you need to learn and understand C++, and this does lead to questioning why we aren't just using C++ since by this point the user is perfectly capable of using C++, while they still need to learn the arcane bits of GObject on top of that to start using it, and it will only ever be inferior to doing the same thing in C++. Most potential contributors will find the barrier to entry much lower if using C++ since it's so much more simple and obvious.

class MyWidget : public Widget { … };

is easy; it's C++ 101, right out of the book. But doing the same with GObject is complex and fragile--several pages of boilerplate. Any typos or mistakes and it's broken, leading to crashes or misbehaviour. And keeping the vtables and all the macros up to date with code changes is a manual process; with C++ it's all done and checked for you by the compiler. Think about how much work is needed to refactor the inheritance hierarchy. It's maybe a 1-2 line change in C++, but with GObject you have to change it in numerous places, with nothing to catch any mistakes. In no way is this robust or maintainable! For most teams, doing this is simply not tenable; C++ does all this with compile-time checking, so giving it up for a more complex and fragile solution makes no sense.

By zealot, I really meant it as referring to people who are so single-minded and blinkered about C that they are not prepared to acknowledge that it has any deficiencies or limitations, and that there are situations where other languages serve better. That's been an attitude prevalent in the Linux community since forever, and I don't think it's always healthy (and I admit I was one of these people up until around 2005). GTK+ was kind-of understandable back in 1998 when we were stuck with GCC 2.95 which was still poor for C++ work pre-Standard; since GCC 3.x this hasn't really been true, and today it (and clang++) are absolutely top-notch. If you get to the point in C where you start to think, "hmm, maybe I should use GObject", IMO that's the point where you should be thinking about using C++ instead because that's the point where you're moving outside C's capabilities and sticking with C will lead to a much less robust and maintainable result than C++ (or even Python).

Clasen: Introducing GtkInspector

Posted May 19, 2014 2:29 UTC (Mon) by djcb (guest, #41542) [Link]

Thanks for your insights.

Sure, learning any tool requires a bit of practice (with the exception
of the nipple, I suppose), this is true when writing your own GObjects
just like using, say, std::bind. But nothing that spectacularly
difficult, I think.

I like the C/GObject idiom for the concise and readable client-code it
allows, but I'll happily write C++ when that's a better fit for
the problem I try to solve (even if there's a bit more 'magic'). I
understand personal preferences differ, but you really don't have to
be some irrational reactionary to enjoy writing C code...

I understand that people want to use languages that are a bit more
expressive, but C++ doesn't really fit the bill, I think... looking
forward to some language that can replace both.

Clasen: Introducing GtkInspector

Posted May 20, 2014 0:29 UTC (Tue) by Trelane (subscriber, #56877) [Link]

So you like gtkmm, i take it?

Clasen: Introducing GtkInspector

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

I did like GTKmm. It's clean, well written and documented, and a pleasure to use. It's really what GTK should have been; had this API been the base rather than C, it would have been properly type-safe and robust. And the libsigc++ signals (were) nicer and safer than Qt signals. Probably the nicest C++ language binding I've used.

That said, I ran into minor issues with unwrapped new functionality, and the very occasional bug. Not blockers, just temporary annoyances. But underlying bugs which are still unfixed were rather more serious, like Glade UIs losing all their accelerators when you reparent them into a new window (https://bugzilla.gnome.org/show_bug.cgi?id=129846). Quite a common thing to do if you want all your main UIs as embeddable custom widgets constructed from data rather than code. May be fixed by GTKbuilder, but I haven't tried that; it was still missing some required functionality last time I looked so I stuck with libglademm. These unfixed fairly fundamental things ultimately led to GTK being dropped. Today, there isn't even an upgrade path from .glade to .builder; it was stripped out of glade so you can't even open them. The code will remain using GTK2 GTKmm/libglademm indefinitely; it's not currently worth the expense of a port to GTK3 (it provides zero benefit); it would be less effort to convert from GTKmm directly to Qt should moving from GTK2 be required.

Clasen: Introducing GtkInspector

Posted May 18, 2014 21:27 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> I like the clarity, simplicity of C
C is neither simple nor clear. How many people understand that you need to explicitly cast a pointer to void* when printing it with printf and %p? Who can keep all those silly implicit conversions in their head? How many know what the type of 'a' is? How many C programmers *actually* understand C declaration syntax? Or the silly operator precedences? How many understand what undefined behaviour actually means?

And let's not forget about the gratuitous complexity in user code that is ultimately caused by C's lack of basic features, such as generics or strings, or by its useless and confusing conflation of arrays and pointers, or its lack of orthogonality (it's been known at least since Algol that the distinction between statements and expressions is useless and harmful), or by antifeatures like the preprocessor.

So please, stop spreading this “clarity” and “simplicity” nonsense. By now, we must call C what it is: a really lame, 70ies-era technology that should never have been used outside the kernel in the first place. It should have been shot in the head 25 years ago, and not lauded as an example for clarity and simplicity in 2014.

Clasen: Introducing GtkInspector

Posted May 18, 2014 22:14 UTC (Sun) by brouhaha (subscriber, #1698) [Link]

C combines the power and flexibility of assembly language with the ease of use, reliability, and maintainability of assembly language.

C was a mostly reasonable language for systems programming on a PDP-11 in the 1970s. It's not a reasonable language for much of anything today.

That said, most of my income is from writing C code. :-(

C vs C++

Posted May 19, 2014 8:30 UTC (Mon) by rvfh (subscriber, #31018) [Link]

Ditto. I must use C at work (and then find memory leaks, understand poorly written code, deal with lack of architecture), but I use only C++ at home.

C++ (as most OO languages I suppose) allows a better representation of the problem, and I find that nice C code usually looks like:

blah_init()
void* handle = blah_create()
int rc = blah_do_something(handle, some data)
blah_destroy(handle)

IOW, people have tried to write OO code with a non-OO language. The Linux kernel is full of this kind of things, not even mentioning structures containing function pointers.

So if what people want is to write OO code, I find it easier to do it with a OO language!

C vs C++

Posted May 19, 2014 9:53 UTC (Mon) by ehiggs (subscriber, #90713) [Link]

I'm not sure that everyone agrees that using opaque pointers constitutes an attempt to write OO code in C. There's no polymorphism, or inheritance, or other features more commonly known as making up OO. I think you've just given an example of modular programming and I think we can all agree that this is a good approach for a lot of code.

As far as C++ providing a better representation of the problem, it certainly can. However, in your example writing C code in the manner you've shown has less boiler plate than trying to use the pimpl pattern in C++. In the pimpl pattern class definitions are basically doubled, functions have to jump through a proxy.

C vs C++

Posted May 19, 2014 16:27 UTC (Mon) by zlynx (subscriber, #2285) [Link]

Not necessarily. If you are happy having your functions reference data through the pImpl pointer you just have one set of functions and the private data is in the impl struct. You do always need duplicate constructors though, which is annoying.

C vs C++

Posted May 19, 2014 20:28 UTC (Mon) by MrWim (subscriber, #47432) [Link]

I usually prefer to use abstract base classes for data hiding. There is a runtime cost but that is rarely significant. It cuts down on the duplication you usually incur with pImpl and you often want an abstract base class anyway to enable mocking.

Obviously this doesn't apply to value types, but nor does pImpl usually either.

C vs C++

Posted May 20, 2014 7:59 UTC (Tue) by rvfh (subscriber, #31018) [Link]

How do abstract classes solve the issue of 'I want all my private stuff in the cpp file', hidden from view?

C vs C++

Posted May 20, 2014 11:14 UTC (Tue) by MrWim (subscriber, #47432) [Link]

Like this:

Foo.h:
class Foo : boost::noncopyable
{
public:
    virtual ~Foo();
    virtual void frob() = 0;
    virtual void frell() = 0;
};

std::shared_ptr<Foo> makeFoo(int some, const std::string& args);

Foo.cpp:

#include "Foo.h"

// Force RTTI information out here so it's not spammed all over the place
Foo::~Foo()
{
}

namespace { // Anon namespace, all symbols confined to this translation unit

struct ConcreteFoo : public Foo
{
    ConcreteFoo() {}
    virtual void frob() {
        printf("frob!\n");
    };
    virtual void frell() {
        printf("frell!\n");
    }
};

std::shared_ptr<Foo> makeFoo(int some, const std::string& args)
{
    return std::make_shared<ConcreteFoo>();
}

It's nice because there is the same number of repetitions of method names as if you were just following the usual pattern of declaration in header file, implementation in cpp file. Also, because it's not a value type, you are likely to be holding it by pointer anyway. If Foo were a pImpl instead you would be dealing with a pointer to a pImpl class which is essentially a pointer anyway.

You can also do things like force management by shared_ptr by changing the factory function. You don't need to faf around with making make_shared a friend or having friend factory functions or anything like that.

Another nice aspect is that you don't need to use private: anywhere. The fact that all the code is in the cpp file offers stronger encapsulation than private:.

The one down-side I'm aware of is that it makes it a little tricker to write white-box tests of the implementation details of the class. The solution I've used in the past is to just #include "Foo.cpp" into my tests. Mostly I prefer black-box testing anyway though so it's not a big deal.

C vs C++

Posted May 20, 2014 14:26 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

How do you deal with friend classes in this case? "private: friend ...;"? My example is a "pool" being able to have extra access to the objects in it basically to tell the objects information only it could know.

My problem with it is that now you force shared_ptr on it. What if I want a unique_ptr?

C vs C++

Posted May 20, 2014 18:24 UTC (Tue) by MrWim (subscriber, #47432) [Link]

How do you deal with friend classes in this case? "private: friend ...;"? My example is a "pool" being able to have extra access to the objects in it basically to tell the objects information only it could know.
I'm not sure I understand what you're describing, but one way would be to define the pool and the objects in the same cpp file where they can be aware of each other. No friends required ;). Ultimately this technique isn't a panacea and you can apply it where it works and don't where it doesn't. It just seems to me that it's superior to pImpl for most use-cases but seems to be under-used as a technique (unlike pImpl).
My problem with it is that now you force shared_ptr on it. What if I want a unique_ptr?
That was just an example of something that is convenient to do with this approach. Of course if you want a unique_ptr then return a unique_ptr.

C vs C++

Posted May 20, 2014 18:30 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> I'm not sure I understand what you're describing, but one way would be to define the pool and the objects in the same cpp file where they can be aware of each other.

These are the two largest source files in the repo already :) . There are actually a few things in that class[1] that break pImpl cleanliness anyways: templates which call a private method.

Basically, only the 'pipeline' class knows what the "core frequency" is, so it is locked down to be private and not exported from the library to protect it.

[1]https://github.com/Kitware/sprokit/blob/master/src/sproki...

C vs C++

Posted May 20, 2014 16:53 UTC (Tue) by ehiggs (subscriber, #90713) [Link]

Thanks for sharing this. It's not too bad but I am surprised we would want to have makeFoo return a shared pointer. Why not make it return a raw pointer so the user can determine how to package it? Is this a common practice you see in C++ was just this part of a throwaway example?

Thanks

C vs C++

Posted May 20, 2014 17:49 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Depends on how opinionated the library is. Ownership tracking of pointers is still a pain in C++ (which Rust finally addresses). Forcing shared_ptr avoids ownership problems at the cost of a reference count (not the worst thing). I just think that unique_ptr should also be an option here at least.

C vs C++

Posted May 20, 2014 17:55 UTC (Tue) by MrWim (subscriber, #47432) [Link]

It's just an example of something that is hard(er) to do otherwise as it can require faffing about with friend classes/functions. As you say, when there's no reason to return a shared_ptr don't. A unique_ptr or an auto_ptr would be just as good in this example, or if you have an aversion to them a raw pointer would also work.

You could even expose a size variable and a placement new factory function for ultimate flexibility, allowing even stack allocation of these objects, but this would almost certainly be over the top.

C vs C++

Posted May 20, 2014 19:22 UTC (Tue) by JGR (subscriber, #93631) [Link]

auto_ptr has nasty and unhelpful copy behaviour which led to it being deprecated, it should be avoided if at all possible IMO.

unique_ptr is generally the most convenient choice; constructing one has zero cost over just returning a pointer to an allocation with new. It's trivial to then move it to a different smart pointer/whatever as necessary, which is much more of a pain with a shared_pointer. Destructing a shared_ptr also uses atomic operations, which is surprisingly expensive.

If you need that level of allocation flexibility and always return a fixed number of (non-polymorphic) object(s), it's usually simpler to just require that the caller pass in a non-const reference to an existing object to fill in.
For the case of 1 object, you could also use a member function or constructor.

C vs C++

Posted May 21, 2014 14:58 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Well, the problem with unique_ptr is that you need move constructors for it to be fully useful. And that requires C++11 or using boost::move explicitly. Unfortunately, the list of platforms I need to support limit me to shared_ptr since decorating everything with boost::move would likely cause more bugs when it is forgotten.

C vs C++

Posted May 21, 2014 21:07 UTC (Wed) by jwakely (guest, #60262) [Link]

Returning a unique_ptr is better than a raw pointer - it's safe-by-default and also explicit that there is ownership transfer going on. Returning a raw pointer has no advantage over unique_ptr.

If you want to take ownership from a unique_ptr and get a raw pointer that you own it's easy, call release(). You can't do that with a shared_ptr as there could be other owners and there's no way to force them to release their reference.

Clasen: Introducing GtkInspector

Posted May 19, 2014 12:16 UTC (Mon) by etienne (guest, #25256) [Link]

> C combines the power and flexibility of assembly language

Sometimes I wish we had a language at a lower level than C, something generic enough it does not define the number of bits of different types (nor their name), do not intrinsically define if a variable has a pointer to its type description, do not define what is a function or how to call them, do not define operator priority, do not define reserved names, but has the syntax to build that "sugar" by writing the source code for it - something a lot more like an interface to the assembler.

So that you could, at compile time, do:
#include <c++11.h> to write in that language, or:
#include <opencl.h> to write in that other language, or even:
#include <ada.h> or #include <java.h> at the beginning of the file.

Supporting without hacks common languages would be the first step, then you could extend it to support your own needs: multiple types of address pointers, functions which parameter types depends on parameter values, functions only visible on some conditions, your own memory allocation strategy, pre/post conditions...

That should also simplify inter-language calls.

Unfortunately I am not a good enough "computer language grammar" specialist to begin to describe it...

Clasen: Introducing GtkInspector

Posted May 19, 2014 14:03 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Ick. Could we at least kill the #include monstrosities (and the preprocessor in general). Modules have clearly been shown to be better by this time, haven't they?

Also, what you ask for sounds like lisp without parentheses…maybe indentation-aware like Python?

Sounds like what PL/1 was intended to be ...

Posted May 19, 2014 21:31 UTC (Mon) by Wol (guest, #4433) [Link]

In other words, Lisp with even more parentheses :-)

PL/1 is notorious for misplaced parentheses causing subtle bugs - the resulting code usually compiles but means something completely different from what was intended.

But it had a bunch of useful features like integer declarations typically declared the number of bits (and if you were nasty you could declare INT*10(3) which would declare three ten bit integers (and fit them into a 32-bit word, causing the run-time absolute conniptions as it tried to sort out the mess!! :-) Adding the key word ALIGNED iirc would then force them onto word boundaries, so it would probably - too long ago I can't remember - fit each INT*10 into a 16- or 32-bit word.

It was extremely useful in some respects, because you could - EASILY - choose between forcing the data layout how you wanted it, or letting the compiler decide what it wanted. Great for creating data files that could be passed between different computer architectures (until of course you hit big/little endian - things like the ICL 36-bit word were childs play :-)

Cheers,
Wol

Clasen: Introducing GtkInspector

Posted May 18, 2014 18:30 UTC (Sun) by liam (subscriber, #84133) [Link]

www.enlightenment.com

IMHO, a nice compromise between qt and gtk.

Clasen: Introducing GtkInspector

Posted May 18, 2014 18:34 UTC (Sun) by riccieri (guest, #94794) [Link]

I think you meant www.enlightenment.org

Clasen: Introducing GtkInspector

Posted May 18, 2014 18:56 UTC (Sun) by liam (subscriber, #84133) [Link]

(#^.^#)
Thanks!


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