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=20 > available for Windows users, good job! :D Thanks! > Since it looks like you are not using Craft, what build method=20 > are you using instead and why? I am not the one who started the Windows port, but the main reasons for the=20= choice (mxe, http://mxe.cc/) were: * MXE does the cross compilation on linux, useful since the developers did=20= not have a Windows machine or license * Kdenlive does have a lot of dependencies (mostly multimedia libraries),=20 and several of them were already available in MXE. * And maybe when the port was started (around 6-7 months ago), maybe Craft=20= (Emerge) was not as advanced ? However in the future if we find the resources to work on it, it will=20 probably be a good thing to move to Craft since it would allow Windows=20 contributors... Regards jb > Also, to avoid this kind of problems in thr future, are the=20 > patches that Craft applies to qtbase something that can't be=20 > patched upstream? Or are we just waiting for a new Qt release=20 > that already has those patches applied? > > On Dec 27, 2016 9:06 PM, "Kevin Funk" 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=20 >> 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=20 >> 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=3D4a2f1c2457e0104eb9a6135649d3ce4dda312904 >> > >> > (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=20 > Craft [1] -- which > is why we encourage using that one instead of other solutions.=20 > 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@kde.org | http://kfunk.org > >