<div dir="ltr">Ian,<div><br></div><div>Albert was arguing to keep using kio, not to remove it... I believe he's on our side :). At any rate, how were klauncher and kded and such issues solved in kdelibs4 on osx? I can put some time into fixing the kf5 versions to do the same thing.</div><div><br></div><div>BR,</div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 7:02 PM, Ian Wadham <span dir="ltr"><<a href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Inge,<br>
<span class=""><br>
On 29/01/2015, at 12:04 AM, Inge Wallin wrote:<br>
> On Wednesday, January 28, 2015 07:38:23 laurent Montel wrote:<br>
</span><span class="">>> I am agree with Albert if there is a problem with network-transparency on<br>
>> MacOsX it's better to fix it that remove it.<br>
><br>
> That is not the issue. The issue is that it was promised that if you developed<br>
> your program with KDE Frameworks 5 instead of KDElibs, you would get a more<br>
> lightweight program that did not need any daemons to run.<br>
<br>
</span>Was there ever a specification that said that, or better still a detailed design<br>
document, and is there a published plan?  I would really like to know.<br>
<br>
If none of the above, I can see kdeinit5, klauncher5, kded5, drkonqi and kio5<br>
becoming major hurdles in the way of releasing KF5 and Frameworks on<br>
MacPorts and Apple OS X.<br>
<br>
Cheers, Ian W.<br>
<span class="im HOEnZb"><br>
> Now this turns out to be not true.   *That* is what we want, not to remove<br>
> network transparency per se. But if the promise from frameworks 5 is not kept,<br>
> what is there to be done?<br>
><br>
>> And this problem will be in other application.<br>
>> It's not just a problem with kdegames so fix it for kdegames will fix for<br>
>> all application.<br>
>><br>
>> We can't remove feature each time we need to fix on a specific platform no ?<br>
><br>
> Yes, it will be in other applications.  But that is the price you have to pay<br>
> for platform portability sometimes.<br>
><br>
> I never thought it was reasonable to have to start the full KDE desktop<br>
> infrastructure just to run an application from the KDE on, say, Gnome.  But<br>
> that's what we had to do back in the kdelibs days. Frameworks 5 was supposed<br>
> to get rid of that but now it turns out that it doesn't.  The question is: is<br>
> this just not yet implemented or was this design goal abandoned?<br>
><br>
> This is what we need to focus on. Network transparency is *not* the issue.<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
kde-games-devel mailing list<br>
<a href="mailto:kde-games-devel@kde.org">kde-games-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-games-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-games-devel</a><br>
</div></div></blockquote></div><br></div>