D27966: KParts: add PartLoader as replacement to KMimeTypeTrader for parts
David Faure
noreply at phabricator.kde.org
Wed Mar 11 02:16:17 GMT 2020
dfaure added inline comments.
INLINE COMMENTS
> aacid wrote in partloader.h:59
> What's the use for this? The function below doesn't let me chose which one i want (i guess it always uses the one with the most preference?), so why would i need to query which parts are available?
>
> Maybe there should be a version of create that takes a KPluginMetadata?
This is an excellent point, thanks for this feedback.
Loading a part from a given KPluginMetadata is extremely simple, though:
KPluginLoader loader(md.fileName());
m_part = loader.factory()->create<KParts::ReadOnlyPart>(this, this);
Just like any other plugin.
[maybe with md.keyword() as third argument in the future, once that's implemented]
I can see the idea of providing everything that is needed for KParts at the KParts level, so that one doesn't actually have to figure out that the above is the way to do it. But then again, this is the way to do it for any plugin, there's nothing specific about KParts there. So an alternative would be to put this into the documentation for partsForMimeType?
What do you think? Docu or wrapper for a two-liner?
BTW I just implemented part listing (in an actionlist) and part switching in partviewer (which is turning into a mini-konqueror, hehe). It shows that the above works. It also shows that the duplication between new-style JSON and old-style desktop files is a problem, I'll add some duplicate pruning...
REPOSITORY
R306 KParts
REVISION DETAIL
https://phabricator.kde.org/D27966
To: dfaure, aacid, nicolasfella, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200311/91a2bf86/attachment.html>
More information about the Kde-frameworks-devel
mailing list