Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defragmenting Qt and Uniting Our Ecosystem

blog.qt.digia.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Defragmenting Qt and Uniting Our Ecosystem

#51

Post by ori_b »

nicholassmith wrote: post #39
Iftheshoefits wrote: post #16

Earlier quoted context omitted.

I haven't investigated Qt's mobile offerings or "Qt Quick", but I am fairly certain that on X11-based systems the basic core desktop SDK is as native as any other UI toolkit (e.g. GTK), and on Windows it uses the same core libraries that MSVC-written programs use, so it's as close to "native" as it gets there, too. Is that incorrect?

Little bit of a, little bit of b. They use some native controls on X11, and I think they hook into the Windows C++ APIs in places as well, but with the shift to QML I think it's back to being heavily custom control based again.

> They use some native controls on X11

They are native controls on X11. Or, more accurately, X11 has no native controls. The closest is probably XAW, which is so awful it was dropped decades ago. There are QT themes that will use GTK for rendering, though.

(For reference, a screenshot of XAW: http://www.iue.tuwien.ac.at/phd/halama/_13595_figure4289.gif The box with 'Athena Simple Widgets' is what is provided by X11.)

Re: Defragmenting Qt and Uniting Our Ecosystem

#52

Post by jordigh »

milliams wrote: post #42
jordigh wrote: post #35

Earlier quoted context omitted.

So the commercial version indeed is not open source at all? I can't buy the commercial version and give it to my friends? Hm. That's a pity.

Two separate things: 1) The Qt source code. Available under GPL, LGPL or commercial license 2) Some extra proprietary addons. Only available under the commercial license.

I don't get it, why would anyone buy an LGPL exception? They want to keep their own private Qt fork and keep the modifications to Qt locked up? Is the cost of maintaining a private fork really that profitable and much lower than the cost of buying an LGPL exception?

I'm just surprised that's a good business model too. I don't quite understand it. Maybe there's something I could read instead of asking the lazyweb?

Re: Defragmenting Qt and Uniting Our Ecosystem

#53

Post by cyorir »

bananaoomarang wrote: post #7

Qt always seems like a thing that has so much potential, but whenever I use it I'm struck by how it never seems quite good enough. 5 seems a big imporvement on 4 though, so we'll see.

With any tool like Qt, we'll always find things that we want to add or change. Nevertheless, for me Qt is "good enough" in that it suits my purposes better than any of the other toolkits currently out there, like Windows .NET or GTK+, etc.

Re: Defragmenting Qt and Uniting Our Ecosystem

#54

Post by zanny »

jordigh wrote: post #52
milliams wrote: post #42

Earlier quoted context omitted.

Two separate things: 1) The Qt source code. Available under GPL, LGPL or commercial license 2) Some extra proprietary addons. Only available under the commercial license.

I don't get it, why would anyone buy an LGPL exception? They want to keep their own private Qt fork and keep the modifications to Qt locked up? Is the cost of maintaining a private fork really that profitable and much lower than the cost of buying an LGPL exception? I'm just surprised that's a good business model too. I don't quite understand it. Maybe there's something I could read instead of asking the lazyweb?

You don't need to read much, the answer is simple: legal departments.

For most companies, the lawyers don't understand the LGPL or software at all, so they don't understand that the LGPL lets the company distribute binaries with Qt libraries included without any source release requirements. They just need to include a notice that Qt is used and where to get the LGPL parts source.

They just like being able to pay money and "own" the IP.

The only time a company actually needs the commercial option is when they distribute in house modified Qt libraries, because those would be derivative works. And I would really want to know why the hell any company thinks its worth it to buy a commercial license so they don't have to release their modifications to Qt itself. That is just ridiculous.

Re: Defragmenting Qt and Uniting Our Ecosystem

#55

Post by joezydeco »

milliams wrote: post #34
joezydeco wrote: post #8

Just great. As if their licensing cost wasn't high enough, this will probably make it way worse.

I'm not sure it's going to affect it at all. What makes you think it will? All they're doing is spinning off a subsidiary to do what the Qt division is already doing.

And does that have a completely zero cost to accomplish?

As I see it, leaving Qt entirely at the mercy of it's licensing revenue stream and not supplemented by Digia's consulting revenue stream means 1) Qt needs to sell more licenses going ahead or 2) Qt needs to charge more per license. The cost of doing business or paying developers will not be going down any time soon. It can only be flat or, more likely, up. And I don't see Qt license numbers making a radical change upward in the near future.

Re: Defragmenting Qt and Uniting Our Ecosystem

#56

Post by pavlov »

jordigh wrote: post #52
milliams wrote: post #42

Earlier quoted context omitted.

Two separate things: 1) The Qt source code. Available under GPL, LGPL or commercial license 2) Some extra proprietary addons. Only available under the commercial license.

I don't get it, why would anyone buy an LGPL exception? They want to keep their own private Qt fork and keep the modifications to Qt locked up? Is the cost of maintaining a private fork really that profitable and much lower than the cost of buying an LGPL exception? I'm just surprised that's a good business model too. I don't quite understand it. Maybe there's something I could read instead of asking the lazyweb?

LGPL allows only dynamic linking, i.e. the Qt libraries must remain separately loaded binaries and cannot be included into another project in object form.

I could see some reasons why a company would want to statically link Qt libraries into a larger binary. For that they'll need the commercial license.

Re: Defragmenting Qt and Uniting Our Ecosystem

#57

Post by bryanlarsen »

ori_b wrote: post #51
nicholassmith wrote: post #39

Earlier quoted context omitted.

Little bit of a, little bit of b. They use some native controls on X11, and I think they hook into the Windows C++ APIs in places as well, but with the shift to QML I think it's back to being heavily custom control based again.

> They use some native controls on X11 They are native controls on X11. Or, more accurately, X11 has no native controls. The closest is probably XAW, which is so awful it was dropped decades ago. There are QT themes that will use GTK for rendering, though. (For reference, a screenshot of XAW: http://www.iue.tuwien.ac.at/phd/halama/_13595_figure4289.gif The box with 'Athena Simple Widgets' is what is provided by X11.)

Usually when people talk about native controls on Linux, they're talking about the controls used by whatever window manager they're using. By that measure, QT is not native on any of the gnome window managers, but is native on a KDE based distribution.

Re: Defragmenting Qt and Uniting Our Ecosystem

#58

Post by Groxx »

octo_t wrote: post #50
onli wrote: post #4

I'm not too much concerned by this, but it does not sound like a good move. > The unified web page will give a broad overview of the Qt technology, both enterprise and open-source, from a technical, business and messaging perspective. So, the new web page will still have to be fragmented, because it has to serve open source and business visitors. Who speak a completely different language and look for different inform…

plenty of opensource-but-with-enterprise-offerings do the exact same thing, with high levels of success (although I can't think of any examples of this off the top of my head)

Various *nix flavors, MySQL, Asterisk...

Re: Defragmenting Qt and Uniting Our Ecosystem

#59

Post by ChikkaChiChi »

One of the things "missing" from Go is the ability to do a GUI. Some work is being done to build out a QT library, but it seems like the progress on atom-shell and node-webkit may almost make Qt overly cumbersome to work with.

Other than native controls and the potential DOM lag of a webkit interface, is there any particular reason why someone programming in Go, Python, Ruby, etc. would want to engage Qt; assuming a stable, working library?

Re: Defragmenting Qt and Uniting Our Ecosystem

#60

Post by Narishma »

jordigh wrote: post #37
navlelo wrote: post #30

Earlier quoted context omitted.

The commercial business/licensing was sold off to Digia, which eventually bought the whole Qt division.

Yes, I understand this, but Digia went back to GPL and back to selling GPL exceptions like Trolltech did originally?

They never stopped selling commercial licenses, so there's nothing to go back to. The only thing that changed with Nokia is that they made it also available with an LGPL license.
Post reply on HN