This is an automatically generated e-mail. To reply, visit:

Reposting here, proposing to reopen it.

After a while: I think forcing to skip Qt LTS and going for 5.8.0 is not 
Are users of KIO and alike forced to patch KF5 to remove unwanted "black 
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 

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

Reply via email to