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

61–70 of 92 posts

Re: Defragmenting Qt and Uniting Our Ecosystem

#61

Post by FigBug »

zanny wrote: post #54
jordigh wrote: post #52

Earlier quoted context omitted.

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 mone…

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.

Re: Defragmenting Qt and Uniting Our Ecosystem

#62

Post by zokier »

panzi wrote: post #46
jmaygarden wrote: post #26

Earlier quoted context omitted.

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.

Re: Defragmenting Qt and Uniting Our Ecosystem

#63

Post by malkia »

jmaygarden wrote: post #26
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?

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.

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.

Re: Defragmenting Qt and Uniting Our Ecosystem

#64

Post by malkia »

codehero wrote: post #29

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…

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.

Re: Defragmenting Qt and Uniting Our Ecosystem

#65

Post by icefox »

jmaygarden wrote: post #26
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?

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.

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

Re: Defragmenting Qt and Uniting Our Ecosystem

#66

Post by Deusdies »

rat87 wrote: post #24
Deusdies wrote: post #11

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

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 sour…

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

Re: Defragmenting Qt and Uniting Our Ecosystem

#67

Post by wolfgke »

zokier wrote: post #62
panzi wrote: post #46

Earlier quoted context omitted.

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.

Re: Defragmenting Qt and Uniting Our Ecosystem

#68

Post by comex »

ChikkaChiChi wrote: post #59

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…

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.

Re: Defragmenting Qt and Uniting Our Ecosystem

#69

Post by cheez »

ChikkaChiChi wrote: post #59

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…

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.

Re: Defragmenting Qt and Uniting Our Ecosystem

#70

Post by claudius »

codehero wrote: post #29

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…

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

Post reply on HN