<div dir="ltr">Albert, Frameworks developers/maintainers,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 12:43 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El Dijous, 29 de gener de 2015, a les 10:05:01, Inge Wallin va escriure:<br>
<span class="">> On Wednesday, January 28, 2015 20:47:44 Albert Astals Cid wrote:<br>
> > El Dimecres, 28 de gener de 2015, a les 14:04:14, Inge Wallin va escriure:<br>
> > > On Wednesday, January 28, 2015 07:38:23 laurent Montel wrote:<br>
> > > > I am agree with Albert if there is a problem with network-transparency<br>
> > > > 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<br>
> > > developed your program with KDE Frameworks 5 instead of KDElibs, you<br>
> > > would<br>
> > > get a more lightweight program that did not need any daemons to run.<br>
> > ><br>
> > > Now this turns out to be not true.   *That* is what we want, not to<br>
> > > remove<br>
> > > network transparency per se. But if the promise from frameworks 5 is not<br>
> > > kept, what is there to be done?<br>
> ><br>
> > Really? Who promised you that? That's never been the promise, the promise<br>
> > of KF5 is that it's more modular, and yes there's some libs that don't<br>
> > need extra daemons and some that do need them.<br>
><br>
> I actually tried to do some research to find this promise in writing but<br>
> except for pointing it out as a problem in an article on the dot I couldn't<br>
> find any written promise.<br>
<br>
</span>The list on <a href="http://api.kde.org/frameworks-api/frameworks5-apidocs/" target="_blank">http://api.kde.org/frameworks-api/frameworks5-apidocs/</a> has three<br>
items, functional, solution, integration.<br>
<br>
As far as i remember, functional means you can use it standalone, solution<br>
means it needs a daemon and integraion means it needs more stuff (more<br>
daemons?<br></blockquote><div><br></div><div>Is this categorization correct? Has it been checked with a dependency analysis to see that each functional framework is usable standalone? I understood the tiers concept but never did get my head around the functional/integration/solution concept yet, but would like to. At any rate, I think KNewStuff which I'm very familiar with doesn't seem to be usable standalone as the functional status it has implies. It depends on and uses KIO for all network downloads and uploads, which requires a daemon as far as I can tell (and is a solution) so should KNewStuff be changed to a solution also probably? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
> But I do remember bringing up this problem in a<br>
> number of conversations with frameworks developers early in the development<br>
> cycle.  One of those times was in a frameworks meeting at Akademy in<br>
> Tampere.<br>
><br>
> And the developers did say that bringing down the amount of infrastructure<br>
> that the first KDE application on an alien platform started was one of the<br>
> motivations for frameworks. Not the only one, of course, but still an<br>
> important one.<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<br>
> > > > for<br>
> > > > all application.<br>
> > > ><br>
> > > > We can't remove feature each time we need to fix on a specific<br>
> > > > platform<br>
> > > > no<br>
> > > > ?<br>
> > ><br>
> > > Yes, it will be in other applications.  But that is the price you have<br>
> > > to<br>
> > > pay 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.<br>
> > > But<br>
> > > that's what we had to do back in the kdelibs days. Frameworks 5 was<br>
> > > supposed to get rid of that but now it turns out that it doesn't.  The<br>
> > > question is: is this just not yet implemented or was this design goal<br>
> > > abandoned?<br>
> ><br>
> > What is "the full KDE desktop infraestructure" for you?<br>
><br>
> Let's skip the word "full", since I don't really know every nook and crannie<br>
> of the kde infrastructure.  But to start several daemons to be able to<br>
> access a file on another server seems like overkill.  Even one, in fact.<br>
<br>
</div></div>Why starting a program to do something is an overkill? If i want to convert a<br>
pdf to a ps, running pdftops seems totally legit to me.<br>
<br>
Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> I understand (or at least I think I do) that kded is an optimisation that<br>
> loads all the shared libraries once so that all the subsequent kde<br>
> applications don't have to do it. Instead they are forked off from kded with<br>
> the libraries already loaded.  This is a good idea if you know for sure<br>
> that you will be running a whole slew of such applications. But this is not<br>
> a very strong guess on non-KDE platforms and even less so on non-linux<br>
> platforms.<br>
><br>
>       -Inge<br>
><br>
> > Cheers,<br>
> ><br>
> >   Albert<br>
> ><br>
> > > This is what we need to focus on. Network transparency is *not* the<br>
> > > issue.<br>
> > ><br>
> > > > > Cheers,<br>
> > > > ><br>
> > > > >   Albert<br>
> > > > ><br>
> > > > > > Cheers, Ian W.<br>
> > > > > ><br>
> > > > > > _______________________________________________<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>
> > > > ><br>
> > > > > _______________________________________________<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>
> > ><br>
> > > _______________________________________________<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>
> ><br>
> > _______________________________________________<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>
><br>
> _______________________________________________<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>
<br>
_______________________________________________<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></div>