libkonq and ABI stability

Andreas Pakulat apaku at gmx.de
Wed Feb 3 07:53:14 GMT 2010


On 02.02.10 18:17:01, Aaron J. Seigo wrote:
> 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?

As somebody who doesn't work on it, I can't answer that, but...
 
> 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)?

This one is easy. If the answer to a) is "we don't guarantee ABI compat
for the KDE4 lifetime of libkonq", then increasing the SOVERSION is
enough to warrant any ABI change. Apps in extragear and outside of
svn.kde.org will simply use the old version until they switch to the new
one. Distro's can install both version side-by-side (due to the
different SOVERSION) without any trouble.

Of course this assumes that the API you want to remove has a proper
replacement, so apps just need to port to a different API and can still
use the same functionality. Else it would technically still work, but is
probably a problem for those apps as they have no way of updating/using
a newer libkonq that may have important bug and security fixes.

Andreas

-- 
You will be aided greatly by a person whom you thought to be unimportant.




More information about the kfm-devel mailing list