Defragmenting Qt and Uniting Our Ecosystem | Hacker News Reader

Defragmenting Qt and Uniting Our Ecosystem

blog.qt.digia.com

134 pointsdrgvond91 comments

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?

You say "other than", but native controls are a big deal. As an OS X user, I for one would strongly avoid using an application that uses (often generally poor, almost always slightly off with keyboard shortcuts and such) HTML replacements for native UI. (For the record, I don't use Atom, but in that case the horrid performance is more important.)

Actually, Qt suffers from this as well compared to native Cocoa, because of both small issues with reimplemented controls (as of recently, anyway) and, more importantly, generally Windows-focused UI paradigms. But it's not as bad as HTML.

When I hear "GUI" and "native", wxWidgets immediately pops up in my head, which is a decent framework and wraps native controls. I wish it had more publicity.

After trying to maintain a wxWidgets project about a year ago, I'm afraid I must disagree. It wraps native controls, but it is a horrible broken framework. Among other things,

- It uses macros instead of C++ templates in order to support ancient compilers.

- To handle events, you're supposed to make an enum for your controls and go through these EVENT_TABLE macros - it works, but generally it's a mess compared to nicer frameworks like Qt.

- Threading support is really lame, e.g. this quirk of AddPendingEvent: http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a07...

- Then and probably still today, OS X Retina support was completely broken. Not a great turnaround time - it was already a year after the release of Retina laptops.

Well, it has its drawbacks, but if native controls are a requirement, what alternative cross-platform good enough frameworks do we have?

Agree about your points, except you can Connect (dynamically) event handlers as in Qt's connect. From wx 3.0 you can actually Bind any function (i.e. it is not necessary to derive from wxEvtHandler). I always preferred this to Qt's blind, non-cpp, runtime evaluated connect's. At least you get a compiler error when it is not possible to connect.

wxWidgets looks like a reimplementation of MFC almost. This might be good for some people or bad for others. MFC is/was the Microsoft Foundation Classes, an OO framework for doing GUI development on Windows that dates back to 1992.

I'm guessing that when wxWidgets was originally written (also 1992!), the author(s) thought it would ease the transition from writing Windows-only apps to cross-platform apps. wxWidgets has a very similar class hierarchy and uses the same preprocessor techniques.

Not that knowing any of that background makes it any more pleasant to work with.

Yeah... That's the only thing keeping the world from adopting Go.

It is possible that Webkit will eventually become the UI container/framework of choice, however, and I'm sure at that point Qt will adapt. I'm still torn between them choosing QML (which is great!) vs HTML/CSS/JS purely for popularity reasons. I would wish for QML to win because it is a dream to work with.

You can try using go-qml https://github.com/go-qml/qml

Digia, and anyone else who might still use it, please remove AddThis.

http://www.propublica.org/article/meet-the-online-tracking-d...

What exactly is the difference between this canvas tracking tech and cookies, flash cookies, and panopticlick? That just sounds like FUD because people are just learning about this.

blocked by disconnect.me , just as the rest of this tracking bullshit.

Can't you just block that by using noScript? Or is this an issue because you have to use noScript to block it?

Genuinely curious as all I use is an ad blocker and have no experience with noScript.

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.

I agree, and I wonder how much further ahead it would be if they'd switched to the current licensing scheme years earlier.

Other than writing native for each platform, which I don't have time to do, I haven't seen any good alternatives to Qt. And I'm not going back to MFC.

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?

That is incorrect unless things have changed in the last few years. Qt does not use native controls. Everything (list boxes, tables, buttons, etc.) is drawn and implemented by the Qt library.

wxWidgets takes the opposite approach and uses native controls. I imagine they support a lot fewer platforms as a result. It's much easier to port when all you have to do is abstract the native drawing and input routines.

One might want to add: There are not "native" controls under X11 (and I guess also Wayland). There Qt is as native as any other toolkit.

There barely are any "native" controls on Windows either.

Then what is the function CreateWindow in User32.dll for (for all non-Windows developers: this is the WinAPI function to create a control on Windows; it returns a handle to it)?

> http://msdn.microsoft.com/en-us/library/windows/desktop/ms63...

The lpClassName parameter specifies the type of control to create.

The vast majority of controls on any Windows screen in 2014 is created with CreateWindow calls with that parameter set to some value that was added on by RegisterWindowClass though.

I still agree with you that it's silly to say that Windows hardly has 'native' controls.

I was also against not doing native controls for quite long time, mainly because I thought using native controls was the only way to give the system (Windows for example) ability to read the text and other data (screen readers, automation, etc.)

It turns out that's not the case. There is an ACCESSIBILITY api which Qt implements that allows the OS (Windows) to "read" text and control the GUI in the non-native widgets.

This, and the fact that it's much more simpler to do things by subclassing the C++ way.

I also have wxWidgets experience, and here is my summary: Lots of Leaky Abstraction. For example - try to get the current line of a text-edit control - internally what wxWidgets does (or was doing time ago) was to send message to the control, but if the control did not support the message, it had to reparse the whole text, and based on your byte-position count how many CR-LF were there and give that information to you.

e.g. it was hard to predict which operation is going to take this and that much of time.

Qt is not without pitfalls, and missing features - Visual Studio Docking like windows for example that supports multiple monitors, but other than that it was much easier for our team to use it, rather than MFC or the Win32 API, and even wxWidgets.

> is drawn and implemented by the Qt library.

It is not so black and white. For example when there is a button when possible Qt will ask the native system to draw a button with properties x,y,z at location x,y So it might be a QPushButton, but it is the OS X or Win32 library that is doing the painting that the user sees.

Of course on Windows the idea of "native controls" is confusing as many Microsoft apps have their own "native controls", which one is the native control? I am guessing WXWidgets simply picks the lowest common denominator one and moves on.

The deal-breaker for me with wxWidgets was that it "hides" many things in its widgets: for example, I couldn't easily change the color or font of the text in a tabbed widget's tab in python, as those were private variables in the C++ implementation and there were no handles to change them.

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.

I'm wondering what you mean by "not quite good enough". It's by far the best UI toolkit out there and a very high quality application toolkit.

It has shortcomings, but to the point it's unusable?

Not unusable at all! I think my comment sounded more negative than I am about Qt, I enjoy using it but there's a lot of little things, just glitches mostly, that are annoying and detract from it being amazing.

Ah. I understood your comment differently.

It definitely does have shortcomings, but I don't think any library is ever perfect, especially in a project as massive as Qt. I found the Qt community is very open to contributions, feature requests and such when things make sense.

Personally, I think it's great, but I do dislike how it tends to take over the entire project. It's not just UI, it's also QNetwork and QProcess and QByteArray and QSqlDatabase.

Sure, but you're free to use or not use any of these modules. Some core things like QString are harder to get away from but outside of that, it's quite free.

It just feels slightly overwhelming, because it's bloody massive. There's a huge amount of power packed in those interminable lists of methods and properties... So much power inevitably comes with a few quirks.

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.

Dear lazyweb, what exactly is Qt's current business? The blog post makes it sound as if the commercial version of Qt wasn't free software. What freedoms does it take away? I know that Trolltech commercialised Qt by selling exceptions. What's the current business? Also, if 25% of all contributions are coming from non-Digia employees, does Digia require copyright assignment? Does their current commercial model require copyright assignments?

Yes, they release it under GPL/LGPL and make their money on proprietary licenses for users that can't or won't use those licenses. If you want to develop Qt itself and get your changes included you have to sign a copyright assignment agreement that gives Digia the right to re-license your work. See:

    http://qt-project.org/doc/qt-5/licensing.html
    http://qt-project.org/legal.html

They sell a commercial version without any restrictions on usage. In order to accommodate this they do have a copyright license to Digia (https://codereview.qt-project.org/static/cla_individual.html).

> They sell a commercial version without any restrictions on usage.

I understand I can't give it to my friends? That's would be a restriction that free software/open source doesn't have.

You can give it to your friends since all you have is a license to use the source-code under different conditions. It's the same source either way, just you have a special license. Your friends don't have that license and so presumably would be bound by the LGPL.

Apparently not all of it, there are some non-free addons not available under a free license.

Qt is licensed under GPL v3 and LGPL v2.1, but you can also buy a license if you want to use and/or modify Qt in a project without having to redistribute the whole thing under GPLv3 or redistribute your modified Qt under LGPL v2.1.

There's actually a lot of closed-source software you know of that uses Qt in some form: Autodesk Maya, Google Earth, Skype, and Spotify are just a few.

I'm not sure whether all of these teams use the commercial version (some may use e.g. the LGPL version) but it's probably not zero.

http://en.wikipedia.org/wiki/Qt_(software)#Software_using_Qt

So they're back to selling exceptions again? I thought they had stopped when it was owned by Nokia.

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?

No. it's still available under the LGPL.

Digia is doing the same thing Nokia did, which was the same thing Trolltech did. The only difference is that, since the Nokia takeover, the open source version is also available under LGPL. This has not changed under Digia.

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.

The deal was that before Nokia Qt was GPL or commercial but after Nokia bought it they relicensed the open-source offering to LGPL. This obviously reduced the demand for the commercial version but there's still plenty of companies who would buy it for both license and support.

They also have a bunch of addon packs that are proprietary-only. A few of them would be really useful in the free software community too, which sucks, like their graphing QML library.

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?

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.

LGPL isn't compatible with app stores since the user can't relink. So you need a commercial license.

As well, the licensing cost of the enterprise license is $200 a month, that's so cheap compared to a developers salary there isn't a lot of reason not to get it.

Then you can do a static link and make your application a lot smaller (depending on what parts of Qt you actually use) and make installation simpler.

I really like Qt, but I don't use it for a lot of my simple commandline apps because it would turn what could be a <500KB single .exe into a .exe that requires a few MB of DLLs.

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.

That's not precisely correct. You can statically link proprietary code with LGPL code and even distribute it, but you must also distribute the object code such that the user can re-link against newer/changed versions of the library to create a new static binary.

Phew, for a moment I thought that they will be focusing only on enterprise licenses and make Qt closed-source (which would probably be a suicide).

It would be suicide and it would also be impossible due to the agreement with the KDE Free Qt Foundation (http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p...).

note

http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p...

> The Foundation has a license agreement with Digia and Nokia. 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.

Amazing, I did not know this (and I use KDE). Thanks.

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

Might be a good thing if it leads to a better website, might reflect good changes, but that alone sounds rather complicated. In my eyes it is not bad to have a fragmentation between sites targeting business users and those who do not, and it seems sound to have the one for business users in the reign of the company.

The new company seems to be the real news (at least it was new to me), that Qt will be managed by a company focussing solely on Qt.

Yeah, but the new company will be 100% owned by Digia.

So basically this is a nice move from Digia to consolidate its ownership and leadership of Qt.

I guess its similar to what Google does.

Or a move from Digia to prepare a sale - it's much easier to sell something like QT if you also include all the relevant developers in one nice package.

Or maybe it's a way to insulate Digia from losses resulting from QT operations, who knows?

I have to say I'm happy they'll review the installer though; ever since they started packing their own compiler, I got the feeling things became a bit more chaotic than they were.

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

Also, see Wordpress[0][2] and Vanilla Forums[1][3]. They both offer an open source version that you can download and self-host, and a commercial offering which they host and you can customize through a limited set of themes and plugins.

Open source, community edition:

[0] http://wordpress.org/

[1] http://vanillaforums.org/

Hosted version with customization via themes and plugins:

[2] https://wordpress.com/

[3] http://vanillaforums.com/

I would have counted wordpress as a counter example: they offer both, but on different sites (wordpress.com vs wordpress.org).

One thing you do not see fragmenting are command-line tools, because people tend to agree on their function(1). However, QT is huge; its scope goes far beyond GUI functionality, into string classes, SQL databases, networking, etc. And moc, its C++ code generator. More scope equals more possible disagreements, which necessarily entails fragmentation.

I tried installing the Qt version of wireshark using exherbo (one of the most minimal Linux distros) and it wanted MySQL as a dependency! For me, if you cannot build a well focused tool with a GUI toolkit it's not worth using.

1 (sure different Unices have different options, but that is more historical)

> it wanted MySQL as a dependency! For me, if you cannot build a well focused tool with a GUI toolkit it's not worth using.

How is Wireshark not well focused? It probably uses a mysql database for its activity history (note: I didn't look, its just a common design pattern). I mean, it seems like a program like Wireshark would be better suited by a simpler sqlite database, but its really up to the project lead on these things.

Wireshark doesn't use MySQL or any other SQL backend. I'm not sure what sort of dependency chain would trigger the installation of MySQL but it's unusual to say the least.

Almost certainly a packaging error where Wireshark depends on Qt and Qt includes all modules, including QtSql.

Looking at the exherbo package list, it seems that the qt4 package has an optional (or opportunistic) dependency on mysql. And on sqlite. So it ought to be possible to do the equivalent of an `apt-get install --no-install-recommends` to get it without mysql.

That sounds like a tenuous thing related to wireshark, not Qt, which is a little odd. You can build command line tools with Qt (surprise!) that are light and focused, but have the benefit of a number of frankly excellent standard library replacements.

It probably only wanted mysql-client (the API library), not the whole server. At least on debian that's the case.

If the distro is not taking care of splitting the packages in "dev" (headers and .a files), "client" (.so files), "server", etc. then it'll have such problems.

I doubt having few extra kb of client is such a big deal, especially if you decide to use Qt.

Also in debian (I think) the Qt sql part is also optional.

> One thing you do not see fragmenting are command-line tools, because people tend to agree on their function(1).

Hm. top and htop do mostly the same thing. So do more, less and most, as examples of multiple tools for the same job. awk behaves slightly different on MacOS X. Bash is stuck at version 3.x there, too, for examples of different tools on different platforms. Some Linux distributions come with dash as /bin/sh, whereas others still use bash there. Which version of gcc you get in a given distribution seems mostly down to luck, as examples of fragmentation even within one operating system.

I wouldn’t say that there is no fragmentation of command-line tools, but maybe the individual fragments are smaller (as opposed to the two to four larger “fragments” GTK, Qt, MacOS X and Windows).

The mysql dependency is an exherbo packaging quirk. Hardly the fault of the the toolkit.

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.

Are there other options to improve the financial health of the Qt ecosystem?

Sadly, no. And it's distressing. Especially as I finish work on a UI system that's using it.

Microsoft is supposedly consolidating their Windows versions, including desktop and mobile. Too bad they didn't support Qt on mobile from the beginning, as it could have seeded their ecosystem.

It's a shame that Digia pricing has no elasticity for the large pool of indie mobile developers. It's either LGPL for zero revenue or $$$ for a paid license. Within that large price gap are products which perform "cloud compilation" that require handing over your IP to a 3rd-party. MoSync had a good open-source run with their LLVM toolchain, but didn't reach stability.

If a Qt-native mobile OS had been successful (e.g. Meego pre-Elop), the picture would be different today. Engineering feats have brought Qt to Android and iOS, but it's not the same as being a first-class business citizen of the platform.

Engineering feats have brought Qt to Android and iOS, but it's not the same as being a first-class business citizen of the platform.

Very true. At one point I was considering a Qt application on top of Android to let some legacy products continue to run on a modern platform. Until I saw that Digia was pretty much asking for a full Qt license royalty on that platform. At that point it became "screw this, I can just contract a Java developer to port it and it will come out WAY cheaper".

I wish they could just spin off a QT3-era widget library for cross platform desktop only stuff. All the new QtQuick declarative and mobile stuff just confuses me and gets in the way. Believe it or not, Qt used to be a small and lightweight library.

QWidgets are still there.You don't have to use QtQuick.

And the best part is that in Qt 5.x the individual components are separate source packages. Off the top of my head ... base for the core Qt; widgets for old style widget library; script and declarative for QtQuick; system for I-don't-remember-what; and so on.

If you don't need QtQuick or QtWebKit, you can actually drop quite a few of the packages.

I do not see this as being very practical. I think that many of the people who use Qt today have been using Qt 4.x or Qt 5.x, whereas the people who would use something like Qt 3.x are probably already using something more along the lines of WxWidgets. Changes that made Qt 4 and up different from Qt 3 were made for a reason.

That being said, if a Qt 3-type spin-off were desired and had enough support, I do not see the current developers of Qt (both Digia and outside of Digia) as spending a lot of time on it, since most of the focus is specifically on the features you would want to avoid.

My suggestion would be that if you want a widgets-only version of Qt, you could gather a group to create an LGPL spin-off of Qt 4 or Qt 5 using the specific modules you want as a starting base. (I may be wrong, but I think Qt3 still has messy licensing from the Trolltech days).

Original announcement at http://qfx.quartalflife.com/Clients/fi/digia/rss/newsentry.a...

For me , Qooxdoo (qooxdoo.org) making QT almost obselete. Qooxdoo + CEF (nodewebkit, atom-shell) making QT un-necessary. I wonder why qooxdoo is very less known around here.

How big is Qt's commercial market? Any breakdown by license fee and professional consulting fee?

What will be KDE's future?

Completely unchanged of course.

Reply on news.ycombinator.com