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" <kf...@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 | kf...@kde.org | http://kfunk.org
