Qt 5.5 Alpha Finally Released

[carewolf]

Why are distributions shipping Qt 5.5 but not libxcb 1.11? (especially if Qt 5.5 depended on libxcb > 1.11?

I said applications. Qt is an application toolkit with the selling point that Qt applications run on all major operating systems and versions. It wouldn't be very be very good if it didn't support the most common linux distro versions.

[zanny]

I said applications. Qt is an application toolkit with the selling point that Qt applications run on all major operating systems and versions. It wouldn't be very be very good if it didn't support the most common linux distro versions.

You don't run Qt applications on Linux distros as statically linked blobs, you use the shared Qt libraries, and we are talking about the static render loop implemented as a function of the XCB plugin. Your distributed application will be using system plugins unless you are doing it wrong and distributing your own, and in those cases Qt 5.5 applications would, well, one almost certainly not work on older Ubuntus anyway because it won't provide Qt 5.5 libraries anytime soon, and the alternative is you are binary compatible with older Qt versions (and Qt is ABI stable throughout the 5.X releases) and then you are using the loopless implementation anyway.

Even then, nothing stops distributions who don't want to enable the render loop functionality yet from setting an environment variable like QSG_RENDER_LOOP to basic and then it does not matter what you built against, all Qml applications would use the unthreaded renderer, and just including it in their distribution of Qt 5.5.

The only exception is when you install a user application that "forgets" to have an XCB requirement of 1.11 or newer, which then crashes due to the XCB bugs from last year. That is hardly a reason to cripple the toolkit, especially since even 5.4 was a forward shipping version that will be stuck on Ubuntu 15.04 for the next six months without a threaded renderer.

[carewolf]

You don't run Qt applications on Linux distros as statically linked blobs, you use the shared Qt libraries, and we are talking about the static render loop implemented as a function of the XCB plugin. Your distributed application will be using system plugins unless you are doing it wrong and distributing your own, and in those cases Qt 5.5 applications would, well, one almost certainly not work on older Ubuntus anyway because it won't provide Qt 5.5 libraries anytime soon, and the alternative is you are binary compatible with older Qt versions (and Qt is ABI stable throughout the 5.X releases) and then you are using the loopless implementation anyway.

Even then, nothing stops distributions who don't want to enable the render loop functionality yet from setting an environment variable like QSG_RENDER_LOOP to basic and then it does not matter what you built against, all Qml applications would use the unthreaded renderer, and just including it in their distribution of Qt 5.5.

The only exception is when you install a user application that "forgets" to have an XCB requirement of 1.11 or newer, which then crashes due to the XCB bugs from last year. That is hardly a reason to cripple the toolkit, especially since even 5.4 was a forward shipping version that will be stuck on Ubuntu 15.04 for the next six months without a threaded renderer.

Most Qt application ship with the libraries. You can not depend on the operating system not even on Linux to have the right up to date version. If you have steam on Linux you can try to search for copies of the Qt library in your .steam folder. You will approximately have one for every game you have with a separate launcher or settings app. This is what customers of Qt does and what they need.

That doesn't mean the system Qt version can't enable a hard dependency on a newer libxcb version. If you have a usecase where multithreaded GLX makes a obvious improvement, please open a Qt bug with example code, and it will be easier to justify adding a configure option specifically for linux system Qt copies.

[doom_Oo7]

I don't know why saying Qt 5.5 depends on Xcb >= 1.11 or whatever you want (I'm not sure the exact version the fix went in, but I know 1.11 was August of last year) would be a bad thing, versus crippling QtQuick2 performance on the majority of hardware any distro runs on. It seems so backwards to say "our software is just broken and does not work as intended for all users of this modern graphics library, because we want to make sure users of Ubuntu 14.04 can run Qt 5.5 without Canonical having to push an updated libxcb along with it... when older versions of that library are known to be broken?"

14.04 ? I'll certainly have to use it on 12.04.

[zanny]

14.04 ? I'll certainly have to use it on 12.04.

You'll have to use Qt 5.5 on 12.04, but will be unable to install a non-broken instance of libxcb?

This is what customers of Qt does and what they need.

Which has nothing to do with libxcb version support. If you already have a runtime of replacement libs for everything from libstdc to sdl, you can also provide an older or newer libxcb. If you end up in a situation where you need to replace too many libraries on the system... maybe the distro should just ship freaking libxcb 1.11 so its not broken. I consider that in the same class of "security patching" as most OTA updates to an LTS.

All those application distributors should be salty that their software is running its render code in a blocking main thread that makes it feel like molasses on any Intel based system or anyone not using an aftermarket GPU driver on Linux. Theres nothing wrong with saying "this library, AKA, broken libxcb 1.5 (the current minimum target) is now too old, we need newer". Any software shipping older versions of Qt can keep on using the original implementation unthreaded renderer, and new Qt 5.5 software can know not to ship to platforms lacking the libxcb versions they need to run the software. Or better yet just not care - if users are having Qt applications crash on Ubuntu 12.04, they will bug report up to Canonical, who would probably ship an updated libxcb since that is whats broken here!

[anda_skoa]

I have to imagine a huge chunk of general Qt users are on Linux with Intel graphics. When the hell are they intending to turn it back on?

I would imagine that all distributions that have a fixed Mesa stack will enable this anyway.
So very likely applications using system Qt won't be affected at all.

Cheers,
_