
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Il giorno 29/ago/09, alle ore 14:02, Aaron J. Seigo ha scritto:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On August 29, 2009, Dario Freddi wrote:<br><font class="Apple-style-span" color="#006312"><br></font>how many applications should be using this (directly or indirectly): few or <br>many? if few, a separate library is a good way to limit symbol growth in our <br>core libs; if many, avoiding another library to link in might be good.<br><br></div></blockquote><div>I think a lot of applications will indirectly use it when KIO will be ported to the new lib.</div><br><blockquote type="cite"><div>will classes in libkdecore such as KAUthorized use it in the future?<br></div></blockquote>KAuthorized is used for kiosks, right? I don't know if policykit fits well for this purpose. It should be researched.</div><div><br><blockquote type="cite"><div>will any widget in kdeui need access to it?<br></div></blockquote><div>Other widgets, no. But there are already one widget and a KAction subclass, provided by my kauth project, that are currently in that branch under kdeui.</div><div><br></div><div>Also, I've made modifications to KCModule class to support authorized kcmodules and those modifications simply can't be split in another lib without rewriting all the kcm support.</div><div><br></div><div>I'd propose to leave the UI part of the project in kdeui.</div><br><blockquote type="cite"><div><br>(and the first stop of libkauth would be kdereview :)<br><br></div></blockquote><br></div><div>It has been in kdereview for three weeks before I started working on the kdelibs integration.</div><br></body></html>