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