On 19/03/14 14:29, Alex Merry wrote:
> While trying to clean up KDE 4 references in KService, I've been looking
> at KLibrary.
>
> This basically does two things: it has a factory() method that has been
> deprecated since before kdelibs 4.0.0, and it does some extra lookup magic.
>
> KLibrary::factory() is used by KPluginLoader for compatibility magic
> (this has been compatiblity code since 4.0.0, I think, and has a KDE5:
> remove comment).
>
> As far as I can tell, the library lookup magic was originally to look
> for plugins in a module directory specified by KComponentData. Now that
> this has been removed, it appears to just messily duplicate QLibrary's
> own internal lookup logic, except that it looks in "kf5" subdirectories
> of QCoreApplication::libraryPaths() (and prints a -- misleadingly worded
> -- warning if a library starting with "libkdeinit5_" was not in this kf5
> subdirectory).
>
> With this in mind, I would suggest ditching the (pre-KDE-4) compatiblity
> stuff and putting KLibrary into kde4support as essentially a typedef for
> QLibrary. KPluginLoader might still want to check the kf5 subdirectory,
> since that's the value of ${PLUGIN_INSTALL_DIR} in KDEInstallDirs.cmake.
>
> Alternatively, we could keep KLibrary where it is, but remove everything
> except for the lookup magic (which probably wants cleaning up).
Note that KSocks and KLibLoader in kde4support both use
KLibrary::factory(). KSocks could be removed, as LXR says nothing uses
it. KLibLoader is used by a depressing number of things, given it has
been deprecated since kdelibs 4.0 (KLibrary is also used by quite a few
things, but that was never totally deprecated).
Alex
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
