KTp/Components/Desktop-wide Approver: Difference between revisions
< KTp
Grundleborg (talk | contribs) braindump some design info |
No edit summary |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{:KTp/Header}} | |||
==Braindump== | ==Braindump== | ||
* Tp:Approver which is a process that runs in the workspace and handles all channel notifications. | * Tp:Approver which is a process that runs in the workspace and handles all channel notifications. | ||
** Perhaps a kded module? | |||
* Needs to have some registry of all installed handlers for each channel type. (will .client files and looking at the bus do for this?) | * Needs to have some registry of all installed handlers for each channel type. (will .client files and looking at the bus do for this?) | ||
** Client files need to be extended so that they contain a translatable string for the name of the handler. | |||
* It can probably register itself as an approver for everything. The CD will never activate an approver if there is no handler. | |||
** It is not clear how to handle the various types of tubes channels. Perhaps the .client files should contain extra information for the approver in this case. | |||
*** Another choice is to specify that every tubes handler will have its own approver. | |||
*** Experiment with krfb/krdc. | |||
* Should respect user preferences for preferred handlers for a given channel type. | * Should respect user preferences for preferred handlers for a given channel type. | ||
** This should somehow intersect with Tp::ChannelDispatchOperation::possibleHandlers() | |||
* Companion kcm module to allow the user to select default text channel handler, default voice channel handler etc... | * Companion kcm module to allow the user to select default text channel handler, default voice channel handler etc... | ||
** Processes that only exist on the bus cannot be considered for the kcm, as we don't know whether they are available when the actual channel is dispatched. | |||
* Talk to sjoerd in #telepathy to make sure we implement this in a way that is as compatible as possible with how Gnome are doing it. | * Talk to sjoerd in #telepathy to make sure we implement this in a way that is as compatible as possible with how Gnome are doing it. | ||
===Steps=== | |||
* As a first step, implement an approver that approves text/call/file transfer channels and use only Tp::ChannelDispatchOperation::possibleHandlers() to select the handler. | |||
* Extend the spec to support the new features. | |||
* Implement the kcm that reads the client files and saves order preferences with kconfig. | |||
* Extend the approver to intersect the kcm's saved order of handlers with Tp::ChannelDispatchOperation::possibleHandlers(). | |||
* Find out what to do with tube channels. | |||
==Roadmap== | |||
{| border="1" | |||
! Status !! Task!! Developers | |||
|- | |||
| NOT STARTED || Extend the telepathy spec to support our use case || George Kiagiadakis <[email protected]> | |||
|- | |||
| IN PROGRESS || Write the daemon itself || George Kiagiadakis <[email protected]> | |||
|- | |||
| NOT STARTED || Write the kcm module for configuring handlers || George Kiagiadakis <[email protected]> | |||
|} | |||
Latest revision as of 00:58, 10 November 2012
Braindump
- Tp:Approver which is a process that runs in the workspace and handles all channel notifications.
- Perhaps a kded module?
- Needs to have some registry of all installed handlers for each channel type. (will .client files and looking at the bus do for this?)
- Client files need to be extended so that they contain a translatable string for the name of the handler.
- It can probably register itself as an approver for everything. The CD will never activate an approver if there is no handler.
- It is not clear how to handle the various types of tubes channels. Perhaps the .client files should contain extra information for the approver in this case.
- Another choice is to specify that every tubes handler will have its own approver.
- Experiment with krfb/krdc.
- It is not clear how to handle the various types of tubes channels. Perhaps the .client files should contain extra information for the approver in this case.
- Should respect user preferences for preferred handlers for a given channel type.
- This should somehow intersect with Tp::ChannelDispatchOperation::possibleHandlers()
- Companion kcm module to allow the user to select default text channel handler, default voice channel handler etc...
- Processes that only exist on the bus cannot be considered for the kcm, as we don't know whether they are available when the actual channel is dispatched.
- Talk to sjoerd in #telepathy to make sure we implement this in a way that is as compatible as possible with how Gnome are doing it.
Steps
- As a first step, implement an approver that approves text/call/file transfer channels and use only Tp::ChannelDispatchOperation::possibleHandlers() to select the handler.
- Extend the spec to support the new features.
- Implement the kcm that reads the client files and saves order preferences with kconfig.
- Extend the approver to intersect the kcm's saved order of handlers with Tp::ChannelDispatchOperation::possibleHandlers().
- Find out what to do with tube channels.
Roadmap
| Status | Task | Developers |
|---|---|---|
| NOT STARTED | Extend the telepathy spec to support our use case | George Kiagiadakis <[email protected]> |
| IN PROGRESS | Write the daemon itself | George Kiagiadakis <[email protected]> |
| NOT STARTED | Write the kcm module for configuring handlers | George Kiagiadakis <[email protected]> |