New authorization library moved to kdereview
mw_triad at users.sourceforge.net
Fri Jul 17 22:38:28 BST 2009
Nicola Gigante wrote:
> Il giorno 17/lug/09, alle ore 22:30, Matthew Woehlke ha scritto:
>> If it is qt-only, and you have no current plans of using KDE
>> libraries, kdesupport (or even an independent repo) might be better
>> since that could better encourage use by qt-only applications as well
>> as KDE.
>> Just a thought...
> It doesn't have to remain qt-only. It just doesn't need kdelibs at the
If it goes into kdesupport, it /will/ need to remain qt-only. So if you
know you are going to be using kdelibs bits in the future, then the
decision is easier :-).
OTOH that means qt-only apps can't use it. That may not be a big deal,
just something to keep in mind.
Another thing to ask is if you want to release with kdelibs or not. This
may be an interesting question, since if you don't want to tie into the
core KDE release schedule, you'll have to go the kdesupport route, but
then you can't use kdelibs. (At least currently, we don't have anything
that needs kdelibs and is needed by kdebase that has an independent
> Do you think kdesupport is a right place? Would the inclusion in kdelibs
> make a wide adoption easier?
For what it's worth, I don't think being in kdesupport would make
adoption any more difficult compared to being in kdelibs. Consider that
you have important bits of KDE such as strigi, phonon and akonadi in
I think the question is best answered based on:
- Will it require kdelibs, or remain qt-only? (Maybe part of it will
live in kdesupport and be qt-only, and part will live in kdelibs?) Do
you want it to be usable by qt-only applications?
- Do you specifically want, or not want, to be tied in with core KDE's
Please do not quote my e-mail address unobfuscated in message bodies.
,= ,-_-. =. Function
((_/)o o(\_)) Flexibility
`-'(. .)`-' Freedom
\_/ The Power of GNU
More information about the kde-core-devel