Defragmenting Qt and Uniting Our Ecosystem(blog.qt.digia.com) |
Defragmenting Qt and Uniting Our Ecosystem(blog.qt.digia.com) |
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?
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.
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.
http://www.propublica.org/article/meet-the-online-tracking-d...
Genuinely curious as all I use is an ad blocker and have no experience with noScript.
It has shortcomings, but to the point it's unusable?
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.
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
http://qt-project.org/doc/qt-5/licensing.html
http://qt-project.org/legal.htmlhttp://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.
> 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.
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 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.
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)
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.
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).
If you don't need QtQuick or QtWebKit, you can actually drop quite a few of the packages.
I understand I can't give it to my friends? That's would be a restriction that free software/open source doesn't have.
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.
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).
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.
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.
Open source, community edition:
Hosted version with customization via themes and plugins:
- 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.
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.
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.
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.
1) The Qt source code. Available under GPL, LGPL or commercial license
2) Some extra proprietary addons. Only available under the commercial license.
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?
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.
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.
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".
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.
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.
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.
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.
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.)
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms63...
The lpClassName parameter specifies the type of control to create.
I still agree with you that it's silly to say that Windows hardly has 'native' controls.
