Qt 6.1 Beta Released With Porting More Modules To Qt6

[JackLilhammers]

It's dead Jim.

I don't think so. In fact it seems quite thriving. Still I wouldn't recommend it over Qt, because it's less user friendly and has fewer features

It's already being worked.

Good to know!

[lowflyer]

I don't think so. In fact it seems quite thriving. Still I wouldn't recommend it over Qt, because it's less user friendly and has fewer features

It really depends on how you define "user friendliness". Is it the IDE? Is "having an IDE" considered user friendly? Copperspice comes with descriptions on how to set up and use it with the Qt IDE. The Qt IDE (Qt Creator) has its own share of problems. Introducing non-standard C++ extensions like signals and slots may well be considered as "user unfriendly". Also think about the non-conforming UTF-8 implementation of QStrings which Copperspice gets right.

The "more features" is the exact the problem of Qt. The immense code bloat of libraries that reinvent the wheel everywhere is the reason why Qt has become such a burden to the Qt developers themselves. In that respect "having as many features as the Qt library" is about equal to "being a football team as good as the one from Greenland".

[JackLilhammers]

It really depends on how you define "user friendliness". Is it the IDE? Is "having an IDE" considered user friendly? Copperspice comes with descriptions on how to set up and use it with the Qt IDE. The Qt IDE (Qt Creator) has its own share of problems. Introducing non-standard C++ extensions like signals and slots may well be considered as "user unfriendly". Also think about the non-conforming UTF-8 implementation of QStrings which Copperspice gets right.

The "more features" is the exact the problem of Qt. The immense code bloat of libraries that reinvent the wheel everywhere is the reason why Qt has become such a burden to the Qt developers themselves. In that respect "having as many features as the Qt library" is about equal to "being a football team as good as the one from Greenland".

Of course, user friendliness depends on the user.
Still, I'd say that C++ is not what usually comes to mind when one thinks of something easy.

Qt Creator has its own problems.
Still it's one of the best open source IDEs. When focusing on C++ it's likely the best.
Also I'd say that Qt Creator is the only free C++ IDE I can think of that comes close to the notion of RAD. Maybe eclipse too?

Again, the single most important parameter to judge a library or more broadly a tool, is by the value it brings to its users.
Features will always add complexity, but if the goal is to lighten the burden on developers, the best way is not to develop anything in the first place.

Maybe they reinvented the wheel sometimes, but usually Qt added stuff years before C++ had its own standard version.
Their implementation of signals and slots is not standard. So what?
Copperspice is uglier and requires the user to write boilerplate code.
I'll take an automatic code generation step over writing boilerplate code every day of the week.

[lowflyer]

Of course, user friendliness depends on the user.
Still, I'd say that C++ is not what usually comes to mind when one thinks of something easy.

Qt Creator has its own problems.
Still it's one the best open source IDEs. When focusing on C++ it's likely the best.
Also I'd say that Qt Creator is the only free C++ IDE I can think of that comes close to the notion of RAD. Maybe eclipse too?

Again, the single most important parameter to judge a library or more broadly a tool, is by the value it brings to its users.
Features will always add complexity, but if the goal is to lighten the burden on developers, the best way is not to develop anything in the first place.

Maybe they reinvented the wheel sometimes, but usually Qt added stuff years before C++ had its own standard version.
Their implementation of signals and slots is not standard. So what?
Copperspice is uglier and requires the user to write boilerplate code.
I'll take an automatic code generation step over writing boilerplate code every day of the week.

Back in 2005 you were perhaps still correct with these points. But the date (and most other stuff) has advanced since while some stuff (the Qt library for example) has not aged that well.

C++ has become simpler in many aspects. Even simpler than C. Don't fall for the bad rumours that many contemporaries still hawk around with.

Naahh. Qt Creator is no longer the best. Over time It has become so unstable that Notepad++ fares better. Even the venerable Microsoft Visual Studio has become a decent alternative. And it's free for open source projects. Next option is Visual Studio Code which itself is open source. And if you don't like Microsoft, there is VS Codium (VS Codium is to Visual Studio Code what Chromium is to Google Chrome). And then there is the "flagship" CLion. It is also free for open source. Eclipse on the other hand is as dusty as Qt Creator. Use the designer separately and any of these become as RAD as good old Creator.

Generalizations like "single most important" or "value to its users" don't help. The downfall of Qt 6, happening as we speak, is caused by the number of features. My ears still echo the outcry of millions of disappointed Qt users across the forest - even in this forum here - when Qt decided to "not immediately" port everything to Qt 6. Having half as many "features" would have made the difference.

And yes, they did re-invent the wheel more than once. These are just a few:

1. a long line of make tools, before dropping the homebrew stuff in favor of CMake: <first make tool>, qmake, QBS
2. QXml, a cluncky alternative to tinyXML, pugiXML and apache Xerces
3. QML, which is "their own" javascript implementation
4. QDir, QFileInfo which are awkward to use but copy "dirent.h" and "boost::filesystem"
5. QThread wich tries to mimic "boost::thread"

I have nothing against code generators. But I prefer *any* decently licensed library over a code generation step that locks me into a specific product.

[Nth_man]

> 3. QML, which is "their own" javascript implementation

[facepalm]

[JackLilhammers]

Back in 2005 you were perhaps still correct with these points. But the date (and most other stuff) has advanced since while some stuff (the Qt library for example) has not aged that well.

C++ has become simpler in many aspects. Even simpler than C. Don't fall for the bad rumours that many contemporaries still hawk around with.

That's debatable. Very debatable.

Naahh. Qt Creator is no longer the best. Over time It has become so unstable that Notepad++ fares better. Even the venerable Microsoft Visual Studio has become a decent alternative. And it's free for open source projects. Next option is Visual Studio Code which itself is open source. And if you don't like Microsoft, there is VS Codium (VS Codium is to Visual Studio Code what Chromium is to Google Chrome). And then there is the "flagship" CLion. It is also free for open source. Eclipse on the other hand is as dusty as Qt Creator. Use the designer separately and any of these become as RAD as good old Creator.

To me it doesn't seem "so unstable". But that's only my everyday experience, just like yours.
Visual Studio Community is one of the best too, but it's not cross platform, and imho is less intuitive to set up than Qt Creator, mostly because it has a larger scope.
JetBrains IDEs are nice, but their policy is a bit more complex than "free for open source". You can look it here: https://www.jetbrains.com/community/opensource/#support

VSCode is fantastic, depending on the project. Turning it in a full featured IDE is a lot more work than just launching Qt Creator.

Generalizations like "single most important" or "value to its users" don't help. The downfall of Qt 6, happening as we speak, is caused by the number of features. My ears still echo the outcry of millions of disappointed Qt users across the forest - even in this forum here - when Qt decided to "not immediately" port everything to Qt 6. Having half as many "features" would have made the difference.

I don't think that those "generalizations" should be discarded that easy when talking about frameworks, and tools in general, but whatever.
I don't really see this downfall you're talking about. And neither do most of Qt developers.
I mean, nobody is forced to switch to Qt 6 tomorrow. Or ever. Qt 5 is still fine.

By the way, without all those hard to port features, there wouldn't have been all those "millions" developers crying because of an incomplete release.
What do you think would have been worse? More features or less users?
And don't tell me that lots of developers don't use Qt because it's too big, because you can choose to include only the things you need.

Of course that doens't mean that they can't make it leaner where it makes sense.
The first thing that comes to my mind is the deprecation of QLinkedList in favor of std::list, but these are details that don't change the whole picture.

And yes, they did re-invent the wheel more than once. These are just a few:

1. a long line of make tools, before dropping the homebrew stuff in favor of CMake: <first make tool>, qmake, QBS
2. QXml, a cluncky alternative to tinyXML, pugiXML and apache Xerces
3. QML, which is "their own" javascript implementation
4. QDir, QFileInfo which are awkward to use but copy "dirent.h" and "boost::filesystem"
5. QThread wich tries to mimic "boost::thread"

qmake is easy and is still fine, especially for small projects. Regardless of it being the industry standard, CMake is complicated.
I don't use QML very much yet, but it makes sense for embedded devices.

For the other points you're saying that I should use Qt, Boost, and another library for XML, when for the most part I'll be fine with just Qt.
Sometimes it's better or even necessary to use different frameworks and libraries, but I prefer to avoid it when possible.
Qt usually allows me to do that. And it's a huge feature.

I have nothing against code generators. But I prefer *any* decently licensed library over a code generation step that locks me into a specific product.

It's a trade-off, just like so many others in software development, and a small one if you ask me

[lowflyer]

That's debatable. Very debatable.

You want to debate on how C++ has not become simpler?

To me it doesn't seem "so unstable". But that's only my everyday experience, just like yours.

Just open a project containing this

#include <unordered_map>

in a pre 4.3 Qt Creator. For a tiny project with only dozends of source files the creator may be ok. Once you use sub-projects and accumulate hundreds of source files, it starts to bite. We had to postpone many upgrades because of "unstabilities". The people at the Qt company were not able to help despite commercial licenses. One of the biggest annoyances is the long start-up time. Sometimes more than 5 minutes if the source tree contains many files - even if they're not source files.

Visual Studio Community is one of the best too, but it's not cross platform, and imho is less intuitive to set up than Qt Creator, mostly because it has a larger scope.
...
JetBrains IDEs are nice, but their policy is a bit more complex than "free for open source".

I'm not a fan of Microsoft, but I have some colleagues that would be up for a wild debate on Visual Studio vs. Qt Creator.

License policies are more complex than most people think. That's as true for JetBrains as it is for Qt and Microsoft. While "Visual Studio Community" is seen as the "free tool from Microsoft", the really free tool is "Visual Studio Express" (read the fine-print licenses in detail, the devil lurks there in person). Despite Microsoft claiming the opposite, it is not possible to develop commercial applications in good faith with the "community" edition. This is only possible with the "Express" edition or the "Visual Studio Build Tools" which are the successor of the no longer produced "Express" edition.

Qt's policy contains the same amount of explosives like Microsoft's. On that background, JetBrain's is actually quite reasonable.

VSCode is fantastic, depending on the project. Turning it in a full featured IDE is a lot more work than just launching Qt Creator.

But once you've set it up, it actually is just as easy as launching the creator.

I don't think that those "generalizations" should be discarded that easy when talking about frameworks, and tools in general, but whatever.
I don't really see this downfall you're talking about. And neither do most of Qt developers.
I mean, nobody is forced to switch to Qt 6 tomorrow. Or ever. Qt 5 is still fine.

By the way, without all those hard to port features, there wouldn't have been all those "millions" developers crying because of an incomplete release.
What do you think would have been worse? More features or less users?
And don't tell me that lots of developers don't use Qt because it's too big, because you can choose to include only the things you need.

Of course that doens't mean that they can't make it leaner where it makes sense.

It's not "more features" versus "less users". The number of features don't make the users. Quality is not measured in number of features. The "number of features" is usually a marketing catch-phrase but in most cases it is a support-nightmare. We see exactly that happening in the Qt 6 release debacle. I guess you wouldn't call it a debacle, but I cannot see how this "million-fold" outcry is helping Qt. Especially because it was completely avoidable in my eyes by not having to port the defunct QtXML first for example.

The first thing that comes to my mind is the deprecation of QLinkedList in favor of std::list, but these are details that don't change the whole picture.

Qt containers use "implicit sharing" and therefore are different from the standard library containers. So you probably want to have both. Implicit sharing was responsible for the performance advantage of Qt compared to other GUI toolkits. But since they are "baked in" to Qt, there is no hope of getting the new polymorphic memory resources from the C++ standard.

qmake is easy and is still fine, especially for small projects. Regardless of it being the industry standard, CMake is complicated.

An industry standard requires more than just "agreeing on the same lie". qmake is no longer supported. It may continue to work for a while if you are on a toy project. Even there it will bite when you're not watching. Try to extract "debug" or "release" or the architecture from the project file.

CMake is only complicated if you read their documentation. It's the sad truth. Just about any blog entry about "Modern CMake" is better than the official documentation. Simple projects are also simple in CMake.

I don't use QML very much yet, but it make sense for embedded devices.

For the other points you're saying that I should use Qt, Boost, and another library for XML, when for the most part I'll be fine with just Qt.
Sometimes it's better or even necessary to use different frameworks and libraries, but I prefer to avoid it when possible.
Qt usually allows me to do that. And it's a huge feature.

Well, it's not as simple as the "batteries included" argument that was so convincing for Python. Not all C++ projects require a GUI. But if you do, I agree that QtXML can be the first choice especially for something trivial. But if you already have experience with e.g. pugixml and then come across QtXML you'll ask yourself "why on earth do I have do fiddle around with that crutch". When your project already uses Boost you're looking at it from the "other aisle" and avoid Qt.

It's a trade-off, just like so many others in software development, and a small one if you ask me

I agree. Or should I say, at least, its debatable.
While I "generally" agree, the case for moc is different. moc is so much baked into qmake and Qt Creator that any comparison will become unfair. moc is the main reason why porting Qt to other systems/platforms/build systems/IDS's is so painful.

If you noticed, we discussed four out of the five fundamental freedoms of software developers, the one we left out is "the freedom to choose programming language":
* the freedom to choose any IDE
* the freedom to use the make tool of choice
* the freedom to use the compiler of choice
* the freedom to change any of the above at will

[JackLilhammers]

You want to debate on how C++ has not become simpler?

I'd say it depends, but I was referring especially to the simpler than C part.
However, I still agree with the old quote by Stroustrup “C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.”

Just open a project containing this

#include <unordered_map>

in a pre 4.3 Qt Creator. For a tiny project with only dozends of source files the creator may be ok. Once you use sub-projects and accumulate hundreds of source files, it starts to bite. We had to postpone many upgrades because of "unstabilities". The people at the Qt company were not able to help despite commercial licenses. One of the biggest annoyances is the long start-up time. Sometimes more than 5 minutes if the source tree contains many files - even if they're not source files.

The project I maintain and develop sits kind of in between, but we've never been bitten by the IDE. So I guess the mileage may vary.
This could be an sign of fragility, but for every complex software you'll find someone to tell horror stories.

I'm not a fan of Microsoft, but I have some colleagues that would be up for a wild debate on Visual Studio vs. Qt Creator.

I'd like to learn to use it better, but I don't want to tie myself to Windows because of Visual Studio.

License policies are more complex than most people think.

I agree.

It's not "more features" versus "less users". The number of features don't make the users. Quality is not measured in number of features. The "number of features" is usually a marketing catch-phrase but in most cases it is a support-nightmare. We see exactly that happening in the Qt 6 release debacle. I guess you wouldn't call it a debacle, but I cannot see how this "million-fold" outcry is helping Qt. Especially because it was completely avoidable in my eyes by not having to port the defunct QtXML first for example.

Of course more features make support harder, but, as I said, imho having lots of features is one of the things that make Qt a great application framework.
Furthermore, being an application framework means having a comprehensive set of features.

Qt containers use "implicit sharing" and therefore are different from the standard library containers. So you probably want to have both. Implicit sharing was responsible for the performance advantage of Qt compared to other GUI toolkits. But since they are "baked in" to Qt, there is no hope of getting the new polymorphic memory resources from the C++ standard.

While you're right, I'd say that if you need custom allocators or pmrs you're beyond the scope of Qt containers and building your own solution on top of std containers or Boost ones makes more sense.

An industry standard requires more than just "agreeing on the same lie". qmake is no longer supported. It may continue to work for a while if you are on a toy project. Even there it will bite when you're not watching. Try to extract "debug" or "release" or the architecture from the project file.

It's not recommended for new projects, but it will work fine for at least the life of Qt 6, which will likely be another 7-8 years.

I agree. Or should I say, at least, its debatable.
While I "generally" agree, the case for moc is different. moc is so much baked into qmake and Qt Creator that any comparison will become unfair. moc is the main reason why porting Qt to other systems/platforms/build systems/IDS's is so painful.

If you noticed, we discussed four out of the five fundamental freedoms of software developers, the one we left out is "the freedom to choose programming language":
* the freedom to choose any IDE
* the freedom to use the make tool of choice
* the freedom to use the compiler of choice
* the freedom to change any of the above at will

I think that when talking about frameworks, the languages come with the framework...

[cochise]

> 3. QML, which is "their own" javascript implementation
[facepalm]

A major change in Qt 6 is getting rid of the JS runtime on Qt Quick, making it optional.

[Nth_man]

A major change in Qt 6 is getting rid of the JS runtime on Qt Quick, making it optional.

The difference between that and what someone says ('QML, which is "their own" javascript implementation')...