libkonq and ABI stability

[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).

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