The 0.7 thread

[David Edmundson]

On Wed, Mar 27, 2013 at 3:43 PM, Daniele E. Domenichelli
<daniele.domenichelli at gmail.com> wrote:
> 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.
>
If it became a launcher for other apps what would be the point of it?

> 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
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy