kioslave hardcoded path

Albert Vaca albertvaka at gmail.com
Wed Dec 28 23:30:42 UTC 2016


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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20161229/a47db485/attachment.html>


More information about the Kde-windows mailing list