kioslave hardcoded path

[Kevin Funk]

On Thursday, 29 December 2016 00:30:42 CET Albert Vaca wrote:
> Happy to know that an awesome app as Kdenlive will be soon available for
> Windows users, good job! :D
> 
> Since it looks like you are not using Craft, what build method are you
> using instead and why?
> 
> Also, to avoid this kind of problems in thr future, are the patches that
> Craft applies to qtbase something that can't be patched upstream? Or are we
> just waiting for a new Qt release  that already has those patches applied?

We are trying hard to upstream any patch against Qt, be assured. Most of the 
patches already made it into Qt proper.

As of now there's one patch which is pretty controversial and just in 
craft.git: The one avoiding deadlocks on exit when DBus is involved.

See discussion on:
  https://phabricator.kde.org/D2545

I'm unfortunately helpless with that one, even after taking a lot of my time 
with Thiago trying to find a sane solution to the problem...

Cheers,
Kevin

> On Dec 27, 2016 9:06 PM, "Kevin Funk" <kfunk at kde.org> wrote:
> 
> On Tuesday, 27 December 2016 20:44:48 CET Jean-Baptiste Mardelle wrote:
> > On Tuesday, December 27, 2016 8:29:27 PM CET, Kevin Funk wrote:
> > > On Tuesday, 27 December 2016 20:15:54 CET Kevin Funk wrote:
> > >> On Tuesday, 27 December 2016 00:30:32 CET Jean-Baptiste
> > >> Mardelle wrote: ...
> > 
> > Thanks a lot for your answer.
> > 
> > > Just noticed: The way you're starting the KIO slaves is the one
> > > going through
> > > DBus+klauncher. If that's actually intended, then you might need to
> 
> patch
> 
> > > stuff in kinit.git -- so far everyone avoid DBus+klauncher on
> > > Windows for good
> > > reasons.
> > 
> > Yes, that's correct. We use DBus to communicate between the main
> > application and the rendering process. It seems to work, but I was not
> > aware of these KIO slaves issues.
> > 
> > > Let me elaborate, there are two ways to start kio slaves:
> > > a) KIO asks klauncher via DBus to launch KIO processes
> > > b) KIO directly forks off KIO processes
> > > 
> > > (a) is chosen if an available DBus session is detected, (b) is the
> > > fallback.
> > > 
> > > To *always* use (b), you have two options:
> > > - Make sure there's no DBus session (or dbus-daemon.exe available to
> 
> start
> 
> > > one)
> > > 
> > > - Set the KDE_FORK_SLAVES env var [1], this is what we do in KDevelop:
> > >   https://cgit.kde.org/kdevelop.git/commit/?
> > > 
> > > id=4a2f1c2457e0104eb9a6135649d3ce4dda312904
> > > 
> > > (b) is the tested variant, which works fine for Kate/KDevelop/others...
> > 
> > Using KDE Frameworks 5.29, currently with no install (everything inside a
> > folder), and I can confirm that the KDE_FORK_SLAVES solution works.
> > 
> > However, now a new terminal window (cmd.exe) opens everytime kioslave is
> > called. Any idea haw to prevent that behavior ?
> 
> You need:
>   https://codereview.qt-project.org/#/c/162585/
> 
> This patch is applied to the qtbase build when using KDE's Craft [1] --
> which
> is why we encourage using that one instead of other solutions. There are
> more
> patches in Craft for qtbase, for instance.
> 
> Regards,
> Kevin
> 
> 
> [1] https://community.kde.org/Craft
> 
> > Thanks a lot for taking the time to answer me, we are now very close to
> > launch our Windows test version!
> > 
> > Best regards
> > Jean-Baptiste Mardelle
> > 
> > > Hope that helps,
> > > Kevin
> > > 
> > > 
> > > [1] https://userbase.kde.org/KDE_System_Administration/
> > > Environment_Variables#KDE_FORK_SLAVES
> > > 
> > >> Yes, the installation path is compiled into the binary.
> > >> 
> > >> Though kio looks into two other paths since quite some time now:
> > >>   https://git.reviewboard.kde.org/r/125778/
> > >> 
> > >> Are you using an outdated KF5 version? Or are you installing KF5 into a
> > >> different prefix maybe? For the latter, you might need to
> > >> tweak qt.conf, as ...
> 
> --
> Kevin Funk | kfunk at kde.org | http://kfunk.org


-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20161229/c699ad2d/attachment.sig>