Bug 201797 - When more than one UI plugin is present for a protocol, check for the best parameters match when choosing which one to use
Summary: When more than one UI plugin is present for a protocol, check for the best pa...
Status: RESOLVED INTENTIONAL
Alias: None
Product: telepathy
Classification: Frameworks and Libraries
Component: accounts-kcm (show other bugs)
Version: git-latest
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: 0.4.0
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-28 18:51 UTC by George Goldberg
Modified: 2012-07-06 12:47 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George Goldberg 2009-07-28 18:51:41 UTC
At the moment, code in src/plugin-manager.cpp choses the first plugin it finds for a given protocol/connectionmanager combination. It would be better if it chose the plugin with the closest supported parameters list to the connection manager installed in cases where there are two or more plugins which provide UI for the same protocol/cm combination.
Comment 1 David Edmundson 2011-03-15 15:48:09 UTC
Is this a situation that is ever going to happen?
Comment 2 George Goldberg 2011-03-15 15:50:36 UTC
probably not. let's not bother with this unless it does happen and becomes a problem.
Comment 3 Florian Reinhard 2011-03-15 16:17:16 UTC
Acutally this is a problem, since connection managers/protocols seem to change parameters and/or their names. Changed names could be handled easily by altering handleParamter/registerSupportedParameter. But there are still new/deleted parameters. This actually happens here for haze/icq: my libpurple is too old and parameternames don't match.
Comment 4 George Goldberg 2011-03-15 16:25:13 UTC
What you say is true, but it is a different issue. We are only going to officially develop one UI plugin per protocol/cm tuple, so if different cm version change parameters, these differences should be handled gracefully by that single plugin (and would have been under the old architecture of the kcm - I assume this is still true after the latest rewrite).