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

51–60 of 108 posts

Re: Qt 5.7 released

#51

Post by fisherjeff »

symlinkk wrote: post #22

I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" instead of std::vector and std::list.

I actually find their container classes to be much more usable than the STL containers. Obviously that locks you in to Qt, but if you're already using it for a bunch of other stuff in the same application, that seems like a pretty minor concern.

I also don't understand the hate for moc. It's certainly not the most elegant solution, and far from perfect, but it's effective and 99% of the time you can pretty much forget that it's even happening in the background.

Re: Qt 5.7 released

#52

Post by RotsiserMho »

dkersten wrote: post #50
symlinkk wrote: post #22

I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" instead of std::vector and std::list.

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.

Re: Qt 5.7 released

#53

Post by slavik81 »

symlinkk wrote: post #22

I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" instead of std::vector and std::list.

Originally they made their containers because the standard library implementation was broken or incomplete on many platforms they supported. These days that's not such an issue, but avoiding the standard types allows them to make stronger binary compatibility guarantees.

I think it's a rather nice supplement to the STL. Their containers are optimized quite differently. For instance, all the Qt containers are copy-on-write.

Also, note that QList is not a linked list. QLinkedList is the counterpart to std::list.

Re: Qt 5.7 released

#54

Post by distances »

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.

I'm not convinced that a single UI is desirable for mobile apps. Sure makes sense to share the business logic if you can, but I feel shared UI code will lead to usability compromises.

Re: Qt 5.7 released

#55

Post by distances »

RotsiserMho wrote: post #32
feiss wrote: post #27

Earlier quoted context omitted.

I always wondered why, after all these years, the only alternatives that remain are wxWidgets and Qt. It's a very common pattern, multiplatform gui programming! and after all this time, we only have 2 choices..

It's an incredibly fast moving target. Just look at the GTK mess, let alone keeping a wrapper toolkit up to date with other vendors' OS updates. Plus for operating systems like Windows it's not really clear which GUI technology to wrap. All the wrappers I've seen so far wrap the old school Win32 API but many modern applications are written in WPF or WinRT. Supporting all three would be difficult. Also OS X is a somew…

> All the wrappers I've seen so far wrap the old school Win32 API but many modern applications are written in WPF or WinRT. Supporting all three would be difficult.

Worth noting here that Qt does not wrap the native widgets, it implements its own widgets that are skinned in each platform's native style.

Re: Qt 5.7 released

#56

Post by distances »

CarVac wrote: post #5
smegel wrote: post #3

Earlier quoted context omitted.

JIT for declarative markup? Has that even been done before?

QML has always had it, as far as I know. It makes for a little pause when loading an application as the logic is compiled. I'm not sure what other markup languages have done this, though. They do have a Qt Quick compiler though which removes the need to JIT the user interface; maybe next release it'll see the light of day on the open-source side of things.

As far as I understand it's a bit different trade-off: pre-compiled code with no JIT means faster startup, but a bit reduced performance.

Re: Qt 5.7 released

#57

Post by jernfrost »

symlinkk wrote: post #22

I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" instead of std::vector and std::list.

Actually Qt collections are better designed as they work like regular collections in other languages with e.g. copy on write, making regular copies cheap etc. STL is extremely low level and not as well suited for application programming which you typically do with Qt.

Re: Qt 5.7 released

#58

Post by lallysingh »

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.

You'd think their managers would see the benefits of paying a fixed cost instead of doing their own hacking/development.

Re: Qt 5.7 released

#59

Post by distances »

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…

> 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

I don't think this this is true. My googling is now failing me as I just get results about linking of libraries, but I remember reading it's enough to point to the source if it's unmodified in your application.

Post reply on HN