[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-windows
Subject: Re: kioslave hardcoded path
From: Albert Vaca <albertvaka () gmail ! com>
Date: 2016-12-28 23:30:42
Message-ID: CAAQViEvcunHvYvQMSZh-uQ_rAr1KB0s5npv9oaHe=jZUTwrhqw () mail ! gmail ! com
[Download RAW message or body]
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@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@kde.org | http://kfunk.org
[Attachment #3 (text/html)]
<div dir="auto"><div>Happy to know that an awesome app as Kdenlive will be soon \
available for Windows users, good job! :D</div><div dir="auto"><br></div><div \
dir="auto">Since it looks like you are not using Craft, what build method are you \
using instead and why?</div><div dir="auto"><br></div><div dir="auto">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?<br><div class="gmail_extra" \
dir="auto"><br><div class="gmail_quote">On Dec 27, 2016 9:06 PM, "Kevin \
Funk" <<a href="mailto:kfunk@kde.org">kfunk@kde.org</a>> wrote:<br \
type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div class="elided-text">On Tuesday, 27 December 2016 \
20:44:48 CET Jean-Baptiste Mardelle wrote:<br> > On Tuesday, December 27, 2016 \
8:29:27 PM CET, Kevin Funk wrote:<br> > > On Tuesday, 27 December 2016 20:15:54 \
CET Kevin Funk wrote:<br> > >> On Tuesday, 27 December 2016 00:30:32 CET \
Jean-Baptiste<br> > >> Mardelle wrote: ...<br>
><br>
> Thanks a lot for your answer.<br>
><br>
> > Just noticed: The way you're starting the KIO slaves is the one<br>
> > going through<br>
> > DBus+klauncher. If that's actually intended, then you might need to \
patch<br> > > stuff in kinit.git -- so far everyone avoid DBus+klauncher on<br>
> > Windows for good<br>
> > reasons.<br>
><br>
> Yes, that's correct. We use DBus to communicate between the main<br>
> application and the rendering process. It seems to work, but I was not<br>
> aware of these KIO slaves issues.<br>
><br>
> > Let me elaborate, there are two ways to start kio slaves:<br>
> > a) KIO asks klauncher via DBus to launch KIO processes<br>
> > b) KIO directly forks off KIO processes<br>
> ><br>
> > (a) is chosen if an available DBus session is detected, (b) is the<br>
> > fallback.<br>
> ><br>
> > To *always* use (b), you have two options:<br>
> > - Make sure there's no DBus session (or dbus-daemon.exe available to \
start<br> > > one)<br>
> ><br>
> > - Set the KDE_FORK_SLAVES env var [1], this is what we do in KDevelop:<br>
> > <a href="https://cgit.kde.org/kdevelop.git/commit/" rel="noreferrer" \
target="_blank">https://cgit.kde.org/kdevelop.<wbr>git/commit/</a>?<br> > ><br>
> > id=<wbr>4a2f1c2457e0104eb9a6135649d3ce<wbr>4dda312904<br>
> ><br>
> > (b) is the tested variant, which works fine for Kate/KDevelop/others...<br>
><br>
> Using KDE Frameworks 5.29, currently with no install (everything inside a<br>
> folder), and I can confirm that the KDE_FORK_SLAVES solution works.<br>
><br>
> However, now a new terminal window (cmd.exe) opens everytime kioslave is<br>
> called. Any idea haw to prevent that behavior ?<br>
<br>
</div>You need:<br>
<a href="https://codereview.qt-project.org/#/c/162585/" rel="noreferrer" \
target="_blank">https://codereview.qt-project.<wbr>org/#/c/162585/</a><br> <br>
This patch is applied to the qtbase build when using KDE's Craft [1] -- which<br>
is why we encourage using that one instead of other solutions. There are more<br>
patches in Craft for qtbase, for instance.<br>
<br>
Regards,<br>
Kevin<br>
<br>
<br>
[1] <a href="https://community.kde.org/Craft" rel="noreferrer" \
target="_blank">https://community.kde.org/<wbr>Craft</a><br> <div \
class="quoted-text"><br> > Thanks a lot for taking the time to answer me, we are \
now very close to<br> > launch our Windows test version!<br>
><br>
> Best regards<br>
> Jean-Baptiste Mardelle<br>
><br>
> > Hope that helps,<br>
> > Kevin<br>
> ><br>
> ><br>
> > [1] <a href="https://userbase.kde.org/KDE_System_Administration/" \
rel="noreferrer" target="_blank">https://userbase.kde.org/KDE_<wbr>System_Administration/</a><br>
> > Environment_Variables#KDE_<wbr>FORK_SLAVES<br>
> ><br>
> >> Yes, the installation path is compiled into the binary.<br>
> >><br>
> >> Though kio looks into two other paths since quite some time now:<br>
> >> <a href="https://git.reviewboard.kde.org/r/125778/" \
rel="noreferrer" target="_blank">https://git.reviewboard.kde.<wbr>org/r/125778/</a><br>
> >><br>
> >> Are you using an outdated KF5 version? Or are you installing KF5 into \
a<br> > >> different prefix maybe? For the latter, you might need to<br>
> >> tweak qt.conf, as ...<br>
<br>
<br>
</div><div class="elided-text">--<br>
Kevin Funk | <a href="mailto:kfunk@kde.org">kfunk@kde.org</a> | <a \
href="http://kfunk.org" rel="noreferrer" \
target="_blank">http://kfunk.org</a></div></blockquote></div><br></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic