Win: Hide console window for binaries in LIBEXEC

Review Request #124905 - Created Aug. 24, 2015 and discarded

Information
Kevin Funk
kio
master
Reviewers
kdeframeworks
alexmerry, dfaure

Win: Hide console window for binaries in LIBEXEC


  
Kevin Funk
Kevin Funk
Kevin Funk
David Faure
Kevin Funk
Patrick Spendrin
Kevin Funk
Gleb Popov
Kevin Funk
Review request changed

Status: Discarded

Jarosław Staniek

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 :)

Loading...