kioslave hardcoded path

Jean-Baptiste Mardelle jb at kdenlive.org
Thu Dec 29 11:13:08 UTC 2016


On Thursday, December 29, 2016 12:30:42 AM CET, Albert Vaca wrote:
> Happy to know that an awesome app as Kdenlive will be soon 
> available for Windows users, good job! :D

Thanks!

> Since it looks like you are not using Craft, what build method 
> are you using instead and why?

I am not the one who started the Windows port, but the main reasons for the 
choice (mxe, http://mxe.cc/) were:

* MXE does the cross compilation on linux, useful since the developers did 
not have a Windows machine or license
* Kdenlive does have a lot of dependencies (mostly multimedia libraries), 
and several of them were already available in MXE.
* And maybe when the port was started (around 6-7 months ago), maybe Craft 
(Emerge) was not as advanced ?

However in the future if we find the resources to work on it, it will 
probably be a good thing to move to Craft since it would allow Windows 
contributors...

Regards
jb

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



More information about the Kde-windows mailing list