----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124905/#review99926 -----------------------------------------------------------
Reposting here, proposing to reopen it. After a while: I think forcing to skip Qt LTS and going for 5.8.0 is not practical. Are users of KIO and alike forced to patch KF5 to remove unwanted "black windows"? That would look like unfortunate for developer experience of KF5 on Windows. That's what exactly I am facing (and in fact migrating away from dbus too, thus decreasing my use of KF5 unfortunately on Windows). Can we have a temporary fix at ECM of KF5 level (e.g. for Qt < 5.8.0)? Kevin wrote: > Well, you can always patch Qt? > > Emerge applies that patch to qtbase already. So when you use Emerge, your issue is fixed. > Regarding upstream: I didn't push it to anything below Qt 5.8 b/c it's a behavioral change after all. Not a simple bug fix. > I'm lacking the motivation/time do so unfortunately. I've already spent significant amount of my time on this issue, not planning to continue. First, thanks for your time Kevin! At my side, I am patching KF5 but am not very happy since we were close to have a solution and keep it 'proactively' until nobody is using Qt < 5.8.[*] This post isn't a request to grab your time away from the main project. Because I don't know if I'll be posting complete patch, so let's just have a reminder here for others that the workaround at the very downstream level is one of the worst solutions. The only worse thing is potential users of KF5 giving up for so easily avoidable issue. We can even have an option that sets WIN32, just not by default. In theory Qt can be patched but I am not asking about the KDE-windows' development team itself using emerge. Sorry if that was not clear. I am more wondering about where do we want to be with KF5 on Windows for 3rd-party users that would eventually download prepackaged libs. I'd like to think about KF5 like about similar product as Qt is. Stable API with (eventually) binaries available maybe via shiny installer. That's the way of consumption for most users not only on Windows. I think we don't need to discuss that there is Qt 5.6 LTS, why it exists and was demanded, and that users don't compile Qt. And that many people will stay with LTS for a long time. Or with Qt 5.7. And with not the newest compilers for that matter (even if this is unrelated to this very bug). Because what we have is perceived as a bug or at least non-professional behavior. So if patching is performed, and users are motivated to use the KF5 bits in question nevertheless, it's the KF5 that would be patched. While better than asking to patch the Qt, that would be still unfortunate in my opinion because we have all means to act at our end even it "that's not our fault and the one-liner does not belong to KF5". [*] That was more or less an attitude I practiced when developed the 1st KDE on Windows port in 2004 :) - Jarosław Staniek On July 11, 2016, 6:15 p.m., Kevin Funk wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124905/ > ----------------------------------------------------------- > > (Updated July 11, 2016, 6:15 p.m.) > > > Review request for KDE Frameworks, Alex Merry and David Faure. > > > Repository: kio > > > Description > ------- > > Win: Hide console window for binaries in LIBEXEC > > > Diffs > ----- > > src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc > src/ioslaves/http/kcookiejar/CMakeLists.txt > 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 > src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 > src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e > src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc > > Diff: https://git.reviewboard.kde.org/r/124905/diff/ > > > Testing > ------- > > > Thanks, > > Kevin Funk > >
