Qt 5.4 Alpha Shows Off Graphics Improvements, New Qt WebEngine

[Ericg]

I'm aware of the bystander effect; it's a valid point and it was rightfully thrown in my face. But, visual anomalies while resizing a window in Windows is an issue someone is bound to encounter immediately. I confirmed today that it is only canvas that gets affected. The canvas itself resizes properly with the window but the conents don't. I think this is more of a Windows issue than a Qt issue.

Which is an equally fair point. The wiki link wasn't meant as a personal attack, as it seems some took it, merely a slightly amused observation given your word choice-- given the pervasiveness of the issue I am sure that you are correct in that SOMEONE has already reported such an issue. (Also I misunderstood what you were referring to at first. When I first read your post I thought you were talking about a rendering bug while using KDE applications under Windows, which would get far less testing.)

Anyway, I'm using Arch Linux. I haven't filed a bug for my bluedevil issue because I haven't had much of a need to use bluetooth in KDE for the past year, and, I haven't thoroughly investigated the situation to see if there's something I can do about it myself. I haven't attempted to look up existing bug reports either, which is more important than just blindly posting one. All this being said, maybe I'm a little too quick to assume that bluedevil has a lot of issues. BUT, given that bluetoothctl works and bluedevil partially works on the hardware level, but not entirely, this got me to suggest bluedevil has an issue. I'll just have to look more into though, rather than look like a rambling idiot.

Between the problem being BlueDevil related or somewhere else in the stack, I'd say its a safe assumption that the odds are equally fair in either favor without further debugging. I'm no longer on Arch so I cannot comment on whether KDE BlueDevil (I do use Bluetooth frequently so I'd notice) is broken or not on my system. I do remember SOME users were complaining at one point because either Arch or Fedora pulled in the latest upstream BlueZ release and that downstream (BlueDevil and the likes) didn't have support FOR BlueZ 5 yet and therefore were broken by default. The fix was to downgrade to BlueZ 4 or to upgrade to git snapshots of the affected programs.

The last time I used Arch BlueZ4 was the default bluetooth implementation and that BlueDevil worked fine. If they have moved to BlueZ 5 by default and BlueDevil hasn't been equally updated then that would explain your problem, at least in theory. But again: without debugging and hard evidence I am rambling as much as you are, but it may be worth checking into if you wish to sate your curiosity.

[schmidtbag]

Arch currently uses bluez5. You have to install bluez4 from the AUR, and bluedevil is also within one of the main repos (I forget which) so that being said, and the fact that it still works to some degree, suggests it is in fact using bluez5. Unfortunately, the only config file I have for bluedevil is only 1 line long. I'll have to look more into it I guess.

[sthalik]

As per documented known issues, not building QtWebEngine at all for sure.

Funny how they don't care whether OSX can be targetted from anywhere else than OSX itself. As if -xplatform was unsupported kludge.

It's fine, in general. Their build system though? Unique to the project. Not autotools, not scons, not cmake, some atrocity just for the purpose of the project.

[curaga]

From the known issues page:

On Windows, the path to the directory containing the webengine sources can currently not be longer than 33 characters.

Well that's gotta be quality software.

[carewolf]

As per documented known issues, not building QtWebEngine at all for sure.

Funny how they don't care whether OSX can be targetted from anywhere else than OSX itself. As if -xplatform was unsupported kludge.

It's fine, in general. Their build system though? Unique to the project. Not autotools, not scons, not cmake, some atrocity just for the purpose of the project.

Chromium and thus QtWebEngine uses ninja, not qmake (except for starting ninja). It is a lot of work to support building options in Chromium that Google doesn't.

[sthalik]

Last two paragraphs referred to building Qt targetting OSX, not a qtwebengine-specific additional issue.

[anda_skoa]

Well that's gotta be quality software.

Well, nobody here would claim that Windows is quality software, but yeah, restrictions like that make it pretty obvious.

Those limits on command line length is really annoying, bascially all build systems/compilers needs work arounds not needed on any other platform.

Cheers,
_