Bug 89088 - No way to choose KFileMetaInfo handler
Summary: No way to choose KFileMetaInfo handler
Status: RESOLVED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-08 16:38 UTC by kiriuja
Modified: 2020-09-30 04:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kiriuja 2004-09-08 16:38:29 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Debian testing/unstable Packages
OS:                Linux

If more than one kfile handler supports a particular MIME type, one is chosen automatically, apparently at random.

Ideally the meta info from the two or more handlers would somehow be combined.

If that is not possible, the user needs to have a way of choosing one of the handlers through a UI similar to that of File Associations.

For an example of this problem see http://sourceforge.net/tracker/index.php?func=detail&aid=1018799&group_id=71710&atid=532182

Could we please put this on the 3.4 feature plan?

Thanks!
Comment 1 kiriuja 2005-05-23 15:49:22 UTC
One possible approach to this problem is to have one of the plugins run a query
and check if other plugins support the same MIME type. It would then load the
other plugin and call readInfo and writeInfo on it, thus making it possible to
combine information from both plugins on the Meta Info tab in file properties.

In order to do this correctly, the other plugin would need to be loaded through
KFileMetaInfoProvider and stored in its m_plugins dictionary. Unfortunately,
m_plugins was made private in KDE 3.4, making this approach impossible to
implement in a safe way.

Any comments would be appreciated.
Comment 2 Nate Graham 2020-09-30 04:21:49 UTC
This should be fixed now.