Qt 6.2 LTS Will Nearly Be At Feature Parity To Qt 5.15

[miskol]

I already spend some time on migrading my app to Qt6 and it isn't that bad. 😁😁

[Vistaus]

I already spend some time on migrading my app to Qt6 and it isn't that bad. 😁😁

Shhhh, don't let the anti-Qt trolls hear you.

[ddriver]

I already spend some time on migrading my app to Qt6 and it isn't that bad. 😁😁

It largely depends on how much of Qt you use and how you use it. Conservative and canonical usage merits very little, if any modifications to make it qt 6 compatible. If you however make heavy use of any of the functionality that 6 is yet to rewrite for the sake of optimization, portability will collapse.

Of course, you could do a lot better anyway, by simply remembering to never EVER use any 3rd party library or framework directly and all around the place, always put the bare essentials of what you need in your own wrapper api.

This way, when you do have to rewrite or extensively modify, you do it only once at a central location, rather than everywhere all around your application.

It also trivializes ports to other platforms, libs or frameworks.

It is much, much better to take the time to establish what you need and how you use it, rather than just pick off whatever you need from a huge bucket that mandates certain usage patterns and their limitations. Tuck that stuff away, so you can then work your way!

This makes a world of a difference in terms of being forced to be stuck with something outside of your control in perpetuity and being able to sanely migrate away at your convenience.

[ferry]

...
Of course, you could do a lot better anyway, by simply remembering to never EVER use any 3rd party library or framework directly and all around the place, always put the bare essentials of what you need in your own wrapper api.
...

Maybe Qt should rethink their design, so they provide a stable interface that never changes, not even between major releases (i.e. exactly what you suggest to create as a wrapper). Maybe they should adopt an equivalent to "don't break user space" policy. But maybe introducing compatibility breaks is commercially more attractive for them.

[ddriver]

Maybe Qt should rethink their design, so they provide a stable interface that never changes, not even between major releases (i.e. exactly what you suggest to create as a wrapper). Maybe they should adopt an equivalent to "don't break user space" policy. But maybe introducing compatibility breaks is commercially more attractive for them.

They kinda already have that, the public vs private framework api, with private sources stating they are unstable and can change at any time. But the issue is that the public part is not optimally designed.

You can't redo something before you actually do it. Qt's rate of rational design decisions is well below the limit of random chance. Yes, I do mean that if qt decision making was ultimately subjected to a final coin toss, it is very likely that it ends up being better, for the simple reason that statistically it will discard 50% of the options, and qt has, more than anything, a long wobbly line of poorly coordinated missteps.

Whoever is the chief architect there, that person is evidently "still learning", still wasting tremendous amount of developer efforts on under-thought and poorly designed features that merit complete rewrite some years later, and... the rewrite, although optimized to address the obvious weaknesses of the previous one, is still way too far from optimal.

That's why the software development standards of the industry are so pitifully low. Companies use the ever increasing hardware power and their own sheer size to tediously push dreadfully badly designed AND implemented software architectures. They don't really strive for improvement and efficacy, they are just fine with whatever manages to generate profit - the ultimate goal, rather than software excellency. Of course there are exceptions, but most of those have to do with efficacy being a primary requirement in order to make money, or "doing it right because you have to" vs "doing it right for the sake of it".

You can be a "software architect" your entire life and never learn how to actually be a decent one. If you have a crack team of blind and obedient wage slaves and lots of company resources to throw at the bad designs you proudly adhere to... you can't learn from mistakes you don't acknowledge as such. Soon enough, that becomes the norm. And then its forever... There is no process of skill refinement really, you never say "nah, this is not good enough, It can be done better", and you never really try to make it better. Your title is architect but you are more like a clueless interior designer wannabe - your foundation is bad and you don't even care to know about it, you are more of a "ok, put this here, move that there, nah I don't like the color".

I've worked for a multi billion dollar company that is world leader in its field, and the stuff that my team worked on was quite literally, without any literary exaggeration, build from anti-patterns and bad practices, and that was normal to them, as was the side effect of complicating everything, compromising the product and multiplying the operational cost.

[mdedetrich]

They kinda already have that, the public vs private framework api, with private sources stating they are unstable and can change at any time. But the issue is that the public part is not optimally designed.

You can't redo something before you actually do it. Qt's rate of rational design decisions is well below the limit of random chance. Yes, I do mean that if qt decision making was ultimately subjected to a final coin toss, it is very likely that it ends up being better, for the simple reason that statistically it will discard 50% of the options, and qt has, more than anything, a long wobbly line of poorly coordinated missteps.

Whoever is the chief architect there, that person is evidently "still learning", still wasting tremendous amount of developer efforts on under-thought and poorly designed features that merit complete rewrite some years later, and... the rewrite, although optimized to address the obvious weaknesses of the previous one, is still way too far from optimal.

That's why the software development standards of the industry are so pitifully low. Companies use the ever increasing hardware power and their own sheer size to tediously push dreadfully badly designed AND implemented software architectures. They don't really strive for improvement and efficacy, they are just fine with whatever manages to generate profit - the ultimate goal, rather than software excellency. Of course there are exceptions, but most of those have to do with efficacy being a primary requirement in order to make money, or "doing it right because you have to" vs "doing it right for the sake of it".

You can be a "software architect" your entire life and never learn how to actually be a decent one. If you have a crack team of blind and obedient wage slaves and lots of company resources to throw at the bad designs you proudly adhere to... you can't learn from mistakes you don't acknowledge as such. Soon enough, that becomes the norm. And then its forever... There is no process of skill refinement really, you never say "nah, this is not good enough, It can be done better", and you never really try to make it better. Your title is architect but you are more like a clueless interior designer wannabe - your foundation is bad and you don't even care to know about it, you are more of a "ok, put this here, move that there, nah I don't like the color".

I've worked for a multi billion dollar company that is world leader in its field, and the stuff that my team worked on was quite literally, without any literary exaggeration, build from anti-patterns and bad practices, and that was normal to them, as was the side effect of complicating everything, compromising the product and multiplying the operational cost.

To be honest, its probably practically impossible to write a well designed public API for a cross platform GUI framework especially in a language like C++. There are so many non subtle variations between the different platforms (windows/mac/linux) ontop of which you also have to deal with different architectures. The support matrix that this creates alone is insane and then you have to deal with the problem space of GUI's.

Qt is still the best cross platform GUI framework that uses native UI toolkit, you figure this out fast if you try the alternatives.

[ddriver]

Qt is still the best cross platform GUI framework that uses native UI toolkit, you figure this out fast if you try the alternatives.

It does "best" a disservice. A more illustrative wording would be "the least sucky, but still very much sucky".