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

Qt 5.6.0 released

blog.qt.io

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Qt 5.6.0 released

#101

Post by CamperBob2 »

twqtisgreatbut wrote: post #92
CamperBob2 wrote: post #84

Earlier quoted context omitted.

Why not just put your proprietary stuff in a closed-source library and distribute the rest of the source in accordance with the LGPL? What's so horrible about that? Even iOS allows dynamic linking nowadays.

The problem isn't dynamic linking, its the requirement that the end user must be able to re-link a modified version of the LGPL code. So for example, the user should be able to replace the Qt libraries your application links to. On closed platforms like iOS and Android (on Google Play) this isn't really possible. How would your user access your application, modify it and re-sign it?

Presumably your closed-source library has an API that you can document. This is how I handle some hardware-access DLLs for proprietary hardware; the distribution gives you the full source for the main program and the non-proprietary hardware access modules, plus the .DLL with the secret sauce for my own hardware. When you run the app, it loads all of the API-compliant DLLs and adds them to the device-selection menu. Anyone can build their own .DLL with the header files provided, or recompile the existing "open" ones if desired.

For an iOS project, you'd provide a link to the GitHub/Sourceforge page or whatever. It's true that the end user would have to get a signing key from Apple to exercise their rights under the LGPL, but IMHO that still meets the spirit of the law. As far as I'm concerned my obligation ends when I provide the code. Some will disagree (hence GPLv3), but the same problem would exist if I had used a language (or targeted a platform) for which there were no free compilers, and nobody seems to have a problem there.

Re: Qt 5.6.0 released

#102

Post by e12e »

jkarneges wrote: post #32

Most people think of Qt as a UI framework but it's also an excellent foundation for CLI/server apps, as an alternative to the C++ standard library and/or Boost. Qt is split into many sub-libraries so you only link to what you need. For example, one of my projects (pushpin.org) uses Qt but only links to the core and network libs; no GUI/X11/etc.

It's also AFAIK one of surprisingly few sources of a utf-8 aware cross-platform string class/libraries for c++.

Re: Qt 5.6.0 released

#103

Post by joezydeco »

ta0967 wrote: post #52
Ramiuz wrote: post #48

Will it be worth it/extremely hard to learn C++ just to use Qt? (I always read here and reddit about how hard/inefficient/easy to fail is everything is in C++) (Eng. background and software dev full time)

C++ is worth knowing, if only superficially, without any regard for Qt.

Thankfully Qt doesn't go very deep into C++. I've shipped entire GUis without a single template.

Re: Qt 5.6.0 released

#104

Post by FigBug »

tosseraccount wrote: post #41
FigBug wrote: post #19

Earlier quoted context omitted.

Pretty big. If you want to use LGPL Qt you need to dynamically link, so deploying will get you around 20 MB of libraries. You can do a command line JUCE app in a few hundred KB, or a GUI app in not much more.

Is the support for static linking good in JUCE, such that you can release non trivial programs in a single binary with reliance only on system libraries that are pretty much guaranteed to be there.

JUCE used to have a feature where the entire library was distributed as one .cpp and one .h file. It made it very easy to distribute JUCE based source code. The make files were very simple. Unfortunately that is no longer supported.

Re: Qt 5.6.0 released

#105

Post by paines »

justsaysmthng wrote: post #5

I've used Qt many years ago (2007) and I liked the experience, but I had to move away from it because our company decided to go native on all fronts.. For internal tools/prototypes I was using JUCE for my UI needs, which is much smaller in scale that Qt, but it produced very slim executables, was fast and good enough for my needs (plus I loved the API). I still think this a great framework for small UIs and tools, es…

"...but I had to move away from it because our company decided to go native on all fronts.." Wouldn't that be reason to stick or turn to Qt in the first place? Or what am I missing ?

Re: Qt 5.6.0 released

#106

Post by paines »

justsaysmthng wrote: post #5

I've used Qt many years ago (2007) and I liked the experience, but I had to move away from it because our company decided to go native on all fronts.. For internal tools/prototypes I was using JUCE for my UI needs, which is much smaller in scale that Qt, but it produced very slim executables, was fast and good enough for my needs (plus I loved the API). I still think this a great framework for small UIs and tools, es…

"...but I had to move away from it because our company decided to go native on all fronts.." Wouldn't that be reason to stick or turn to Qt in the first place? Or what am I missing ?

Re: Qt 5.6.0 released

#107

Post by wodenokoto »

paines wrote: post #105
justsaysmthng wrote: post #5

I've used Qt many years ago (2007) and I liked the experience, but I had to move away from it because our company decided to go native on all fronts.. For internal tools/prototypes I was using JUCE for my UI needs, which is much smaller in scale that Qt, but it produced very slim executables, was fast and good enough for my needs (plus I loved the API). I still think this a great framework for small UIs and tools, es…

"...but I had to move away from it because our company decided to go native on all fronts.." Wouldn't that be reason to stick or turn to Qt in the first place? Or what am I missing ?

A lot of apps have this non-native QT feel to them. I would guess that's the reason

Re: Qt 5.6.0 released

#108

Post by benlaud »

crudbug wrote: post #7
ronjouch wrote: post #6

Earlier quoted context omitted.

Nothing from the Qt Company itself, but there are some community initiatives around what you're mentioning. This recent mailing list thread mentions a few of them, especially quickflux by community contributor Ben Lau. However, nothing like what you're asking for, QML is clearly not moving in this direction. - http://lists.qt-project.org/pipermail/development/2016-March... - https://github.com/benlau/quickflux/ Now,…

Thanks for the links. The QuickFlux is promising start for the Flux pattern in Qt. I was thinking more on the lines of React Native [1] like support in Qt. Essentially, having React render() function backed by Qt Quick Controls? [1] https://facebook.github.io/react-native/

btw, why you want render() in another framework?

Not exactly the same as React render(), I have started an experimental project to update QML UI by diff:

QSyncable - Synchronize data between models

https://github.com/benlau/qsyncable

p.s In fact, Qt Scene Graph is somehow similar to React. Both of them will only apply the changes to screen. React manipulates the DOM, but Qt manipulates the OpenGL render pipeline.

Re: Qt 5.6.0 released

#109

Post by justsaysmthng »

paines wrote: post #105
justsaysmthng wrote: post #5

I've used Qt many years ago (2007) and I liked the experience, but I had to move away from it because our company decided to go native on all fronts.. For internal tools/prototypes I was using JUCE for my UI needs, which is much smaller in scale that Qt, but it produced very slim executables, was fast and good enough for my needs (plus I loved the API). I still think this a great framework for small UIs and tools, es…

"...but I had to move away from it because our company decided to go native on all fronts.." Wouldn't that be reason to stick or turn to Qt in the first place? Or what am I missing ?

At that time, Qt was not available on mobile platforms and also the look and feel was very "foreign". Executable size was also a factor at the time I think.

Plus probably some other (political) reasons which I don't know or remember too well..

Re: Qt 5.6.0 released

#110

Post by distances »

alatkins wrote: post #91

Can anyone comment on what the uptake of QML is like? Or are most still sticking with the traditional C++/Widgets approach? Are there any major limitations to using pure QML?

I don't know any numbers, but if I'd start a new project, I'd go with C++ logic with QML UI. It automatically steers you to a better application architecture when there's a clear divide between data and representation.

As for limitations, large applications with custom QML may become hard to maintain. I'd expect web development to face the same issue, not sure how they've solved it. Basically refactoring is always a risky operation since you'll find out the breakages only at runtime. For small/medium apps this won't be a problem, but I saw a project with multiple teams on the same codebase for years, and it did cause quite some issues.

Then again, there was no alternative with that project. Widgets wouldn't have been an option at all.

Post reply on HN