The 0.7 thread

Daniele E. Domenichelli daniele.domenichelli at gmail.com
Wed Mar 27 15:43:14 UTC 2013


On 27/03/13 14:28, David Edmundson wrote:
>> My vote goes to having a ktp-tools repository with the initiators (that
>> could be just tiny "wrappers" over a dialog in common-internals, so that
>> they can be used as widgets) and some extra tool (add-contact,
>> ktp-paste-contact) and have the tools as runtime dependency.
>>
> Could it all be one app with a command line arg?
> 
> This is pure brainstorming.
> 
> We have an app that has a command line like
> 
> ktp-start --account foo --contact a at example.com --type text
> 
> OR you can miss out various parameters and the dialog is shown:
> 
> ktp-start --type text
> 
> you get prompted for account + contact ID (with some filtering on
> 
> ktp-start on it's own, you get account combo + text+box
> 
> With tube handling generated from the tubes .desktop files.
> 
> One app means we won't appear in krunner, but our runner can bodge that.


I like the idea, of a "ktp-start" tool but different "types" should show
a different dialog...

  ktp-start --type group-chat -> show join chat room dialog
  ktp-start --type <chat/text> -> show something
  ktp-start --type call -> show dialout dialog
  ktp-start --type filetransfer -> show ktp-send-file dialog


perhaps

  ktp-start --type streamtube --service x-ssh -> show ktp-ssh-contact dialog
  ktp-start --type streamtube --service rfb -> show something

etc...

We should also have a way to pass extra parameters (for ktp-send-file,
etc), for example after the -- argument

The problem is with 3rd party tools, we can't have dialogs for every
single service in common-internals, so we could

1) Have a generic dialog for the service we don't support directly.
2) Have a plugin interface for the dialog window.
3) Let .desktop files specify a launcher (executable) for the service
and use dialogs for supported services and executables for unsupported ones.
4) Have a hybrid, plugin + launcher in .desktop files.
5) Let .desktop files specify a launcher (executable) for the service
and use only ktp-start as a launcher for other executables.

I like number 5), because is the only one coherent, the easier to
implement, and also because some programs (for example kbattleship) have
the launcher embedded, therefore we should be able to start an executable.


Daniele


More information about the KDE-Telepathy mailing list