Hi,

Am 03.02.2010 um 03:17 schrieb Aaron J. Seigo:

> hi :)
>
> what are the ABI commitments for libkonq?
>
> reason i ask is that KNewMenu and KonqMenuActions aren't used  
> anymore in
> kdebase/apps (i have them removed from the build locally, in fact,  
> after
> checking lxr.kde.org).

In Krusader (from extragear/utils) we use these classes to access  
KDE's service menus. Is there any other way for accessing these?

regards,
Jonas

>
> KonqPopupMenuInformation and KonqFileItemCapabilities are similarly  
> unused,
> except by KonqPopupMenuPlugins. in fact, KonqFileItemCapabilities is
> accessible via KonqPopupMenuInformation::capabilties(), and that's  
> exposed
> through KonqPopupMenuPlugin::setup(..). however, according to lxr  
> none of the
> konq plugins in svn.kde.org use  
> KonqPopupMenuInformation::capabilties().
>
> KonqPopupMenuInformation is used by plugins, but it's really now  
> just a
> wrapper around KFileItemListProperties.
>
> ok, the above is certainly not news to anyone (e.g. dfaure ;) who  
> works on
> libkonq.
>
> my questions are
>
> a) can we remove KNewMenu and KonqMenuActions since they are unused?  
> or would
> that violate the ABI guarantees for libkonq?
>
> b) am i correct in assuming that even bumping the .so version of  
> libkonq
> wouldn't be "good enough" to remove KonqPopupMenuInformation and
> KFileItemListProperties since we have apps in extragear using them?  
> (and
> possibly elsewhere outside of svn.kde.org, of course) and if so, is  
> this a
> "KDE 5" thing or would it realistic to do it earlier (say, in KDE  
> 4.6 or some
> suitably future release)?
>
> -- 
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks