The 17/lug/09, at 23:38, Matthew Woehlke wrote:

>
> 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 :-).
>
I can't tell the future, but I wouldn't like to be tied to always  
remain qt-only.

> OTOH that means qt-only apps can't use it. That may not be a big  
> deal, just something to keep in mind.
>
Yeah that's not a big deal.

> 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 release schedule.)
>
I don't have any problem to follow the kde release schedule. Since the  
beginning I didn't consider this library an independent project. I've  
designed it with kde applications specifically in mind. By my point of  
view, it's a kde library. An initial release with kde 4.4 (because 4.3  
is feature freezed, isn't it?) will be ok.

> 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 kdesupport.
>
Ok

> 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?
It doesn't need to remain qt-only, but it currently doesn't need  
anything from kdelibs. I don't care about qt-only applications

> - Do you specifically want, or not want, to be tied in with core  
> KDE's release schedule?
I don't really care. If it will go to kdelibs, I'll follow the kde's  
release schedule with pleasure.

Another thing to consider is that the second part of my gsoc project  
will be to add features to some GUI-related kdelibs classes to  
increase the ease of use of this library. Is it worth to put the code  
(and maintain it) in two different modules, when kdelibs will already  
implement a part of the project?

Thanks,
Nicola