Difference between revisions of "KTp/Components/Desktop-wide Approver"

< KTp
Jump to: navigation, search
 
(3 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==
 
==Roadmap==
Line 16: Line 38:
 
! Status !! Task!! Developers
 
! Status !! Task!! Developers
 
|-
 
|-
| ABOUT TO START || Extend the telepathy spec to support our use case || George Kiagiadakis <kiagiadakis.george@gmail.com>
+
| NOT STARTED || Extend the telepathy spec to support our use case || George Kiagiadakis <kiagiadakis.george@gmail.com>
 
|-
 
|-
| NOT STARTED || Write the daemon itself || |
+
| IN PROGRESS || Write the daemon itself || George Kiagiadakis <kiagiadakis.george@gmail.com>
 
|-
 
|-
| NOT STARTED || Write the kcm module for configuring handlers || |
+
| NOT STARTED || Write the kcm module for configuring handlers || George Kiagiadakis <kiagiadakis.george@gmail.com>
 
|}
 
|}

Latest revision as of 00:58, 10 November 2012

telepathy-kde_med.png

Welcome to the KDE Telepathy Development Wiki

Current Version: 0.9.0
     project_partner_badge.gif
     commits_spark.pngStats at ohloh.net

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.
  • 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 <kiagiadakis.george@gmail.com>
IN PROGRESS Write the daemon itself George Kiagiadakis <kiagiadakis.george@gmail.com>
NOT STARTED Write the kcm module for configuring handlers George Kiagiadakis <kiagiadakis.george@gmail.com>

This page was last edited on 10 November 2012, at 00:58. Content is available under Creative Commons License SA 4.0 unless otherwise noted.