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

Qt 5.7 released

blog.qt.io

Post reply on HN
Print view View original

61–70 of 108 posts

Re: Qt 5.7 released

#61

Post by zerr »

pjmlp wrote: post #35
Nokinside wrote: post #21

Earlier quoted context omitted.

What's wrong with paying for an extremely high quality GUI toolkit? Btw. It's very easy to comply LGPLv3 in proprietary project if you want. 1) If you don't modify the Qt library and link dynamically there is no problem whatsoever. 2) If you modify the Qt library or link statically, it's enough to provide modified version of the Qt library and combined object files that make it possible to relink the application to d…

Many developers feel entitled to get their tools for free, but expect to be able to charge for their stuff, it seems. This is what made RoboVM go comercial AFAIK, as they could hardly make a living from contributions.

Actually, it is "pay upfront" that scares many, I believe. Developers are experimenters - love to play and test many things and in case of commercial success, I think it will be a no-brainier to pay. So I think models such as "pay after your first 10K (or 100K) revenue" work.

Re: Qt 5.7 released

#62

Post by zerr »

pjmlp wrote: post #33
criddell wrote: post #9

Does anybody have experience with other cross platform GUI toolkits that are still actively developed? It's starting to feel like Qt is going to win it all because they are enduring (and excellent).

I had a bad experience with Qt on Android as I had to replicate in QML the native widgets and write JNI wrappers myself. In the end it was more productive to use Java and C++/CX for the views and plain standard C++ for the business logic. However this was in the 5.4 days and I am looking forward to test it again.

Yes, last time I tested it (several months or a year ago), native look of widgets was great out of the box. One thing I wish - if they had exposed all the QML to C++... i.e. to be able to write only in C++, including UI declarations and callbacks.

Re: Qt 5.7 released

#63

Post by Natanael_L »

joshvm wrote: post #11
Aissen wrote: post #8

With LGPLv3, the Qt company is sending a clear signal it's time to pay if you want to use Qt in a device (the industry being clearly anti-(L)GPLv3). It could be the chance for GTK, if they weren't also busy digging their own grave :-/ http://lwn.net/Articles/691131

If you're fine with dynamic linking, then commercial development is still very much possible (though you lose Qt Charts). The only major pain is that you have to supply a copy of the Qt Source if requested - the pain being that a link to the official repo is not enough, you have to be in control of the code. However, I would imagine if you gave someone the option of (a) downloading from the website or (b) paying post…

Your responsibility is to make sure they can get the code for a certain amount of time after you distributed it to them.

So you can point to the origin source if you feel confident that it will remain available for long enough, and if you know you can provide an alternative way to access it if that site goes down (so just keep a local copy, and if somebody tells you that the link is broken then you just share that copy).

Re: Qt 5.7 released

#64

Post by oconnore »

kbenson wrote: post #39
joshvm wrote: post #11

Earlier quoted context omitted.

If you're fine with dynamic linking, then commercial development is still very much possible (though you lose Qt Charts). The only major pain is that you have to supply a copy of the Qt Source if requested - the pain being that a link to the official repo is not enough, you have to be in control of the code. However, I would imagine if you gave someone the option of (a) downloading from the website or (b) paying post…

Seems like there should be a company willing to handle that for you. Take $X for for specific hosting and delivery costs up to Y for particular open source projects you've listed, for Z years.

Have you heard of this sweet version control provider called Github? I hear they might provide a solution for this sort of thing, for free.

Re: Qt 5.7 released

#65

Post by dkersten »

RotsiserMho wrote: post #52
dkersten wrote: post #50

Earlier quoted context omitted.

Serious question because I'm curious: what is the problem with the MOC? Sure, its another build step, but so what? I mean, most large complex software has numerous build steps and MOC is pretty straightforward (and if you use QMake or QtCreator, its pretty much invisible to the programmer). I'm trying to understand why people dislike it so much.

My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I want to use another GUI framework I'd have to refactor that code. Most other build steps occur before or after compilation and are far less intrusive. In short, it's too tightly-coupled to application code.

You mean stuff like the "signal" and "slot" declarations in the class definition?

Wouldn't these types of classes be tied to the GUI framework anyway due to the inherited classes, implemented virtual functions, widget classes referenced and so forth? In my experience (having used Qt, GTK, FOX, FLTK and wxWidgets over the years), different GUI frameworks are significantly different in their APIs and how they work, to the point where I think changing existing code from any of these to any other is a very difficult job, with or without moc.

Re: Qt 5.7 released

#66

Post by joezydeco »

RotsiserMho wrote: post #52
dkersten wrote: post #50

Earlier quoted context omitted.

Serious question because I'm curious: what is the problem with the MOC? Sure, its another build step, but so what? I mean, most large complex software has numerous build steps and MOC is pretty straightforward (and if you use QMake or QtCreator, its pretty much invisible to the programmer). I'm trying to understand why people dislike it so much.

My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I want to use another GUI framework I'd have to refactor that code. Most other build steps occur before or after compilation and are far less intrusive. In short, it's too tightly-coupled to application code.

If I decide I want to use another GUI framework I'd have to refactor that code.

If you're already developing in Qt, what do you think the probability of that is?

Personally MOC is worth the price of admission just to have signals transparently marshaled and queued across threads. It makes life incredibly easy.

Re: Qt 5.7 released

#67

Post by maccard »

criddell wrote: post #9

Does anybody have experience with other cross platform GUI toolkits that are still actively developed? It's starting to feel like Qt is going to win it all because they are enduring (and excellent).

Not exactly the same, but you can use CEF - write your UI in html/css/js.

Re: Qt 5.7 released

#68

Post by salicideblock »

Nokinside wrote: post #21
Aissen wrote: post #8

With LGPLv3, the Qt company is sending a clear signal it's time to pay if you want to use Qt in a device (the industry being clearly anti-(L)GPLv3). It could be the chance for GTK, if they weren't also busy digging their own grave :-/ http://lwn.net/Articles/691131

What's wrong with paying for an extremely high quality GUI toolkit? Btw. It's very easy to comply LGPLv3 in proprietary project if you want. 1) If you don't modify the Qt library and link dynamically there is no problem whatsoever. 2) If you modify the Qt library or link statically, it's enough to provide modified version of the Qt library and combined object files that make it possible to relink the application to d…

You are forgetting that section 6 of GPLv3 still applies. That's the so-called "anti-Tivoization clause" that states that you must give the device owner "Installation information", allowing him to install and execute modified forms on this device.

I understand why you would license your software under this if you want to give end users the SW freedoms developers enjoy. I also understand why many makers of safety-critical devices avoid it like the plague.

Case in point, the automotive industry. Coincidentally, the Qt company has in past few years started engaging automotive companies [1][2]. The move to (L)GPLv3 can be valid and has other reasons besides pushing commercial licensing. But you can't say it doesn't have any impact on the industry.

[1] https://www.qt.io/qt-news/qt-company-launches-automotive-sui... [2] Spot the gauge needles and car body models in the announcement http://www.qt.io/qt5-7/

Re: Qt 5.7 released

#69

Post by jventura »

gulpahum wrote: post #17
criddell wrote: post #9

Does anybody have experience with other cross platform GUI toolkits that are still actively developed? It's starting to feel like Qt is going to win it all because they are enduring (and excellent).

libui [1] is a promising new cross platform GUI toolkit. If I need a GUI for a small cross platform desktop app, I will definitely try it. It uses MIT license, which means there is less headache for commercial applications. It is also more lightweight. I have always felt that Qt has a lot of unnecessary classes. libui has C api, but it would be easy to write a nice c++11 wrapper around it. [1] https://github.com/andl…

libui is a very interesting project but I find it still pretty much alpha: good enough for playing around with it, but not quite ready for production. However it is moving fast, so who knows its state in a few months.. Btw, I'm slowly building a python wrapper (1) and accepting contributions!

(1) - https://github.com/joaoventura/pylibui

Re: Qt 5.7 released

#70

Post by dman »

zerr wrote: post #61
pjmlp wrote: post #35

Earlier quoted context omitted.

Many developers feel entitled to get their tools for free, but expect to be able to charge for their stuff, it seems. This is what made RoboVM go comercial AFAIK, as they could hardly make a living from contributions.

Actually, it is "pay upfront" that scares many, I believe. Developers are experimenters - love to play and test many things and in case of commercial success, I think it will be a no-brainier to pay. So I think models such as "pay after your first 10K (or 100K) revenue" work.

Discussions in posts about commercial libraries / tools developers often have extensive discussion about pricing and free alternatives (Threads about SublimeText come to mind). I wonder if the current sad state of developer tooling (stuck in the 70s in many cases) is because of our reluctance to pay for our tools. Would love to hear what others have to say about this.
Post reply on HN