The 0.7 thread

[David Edmundson]

On Wed, Mar 27, 2013 at 11:33 AM, Daniele E. Domenichelli
<daniele.domenichelli at gmail.com> wrote:
> On 27/03/13 11:20, Martin Klapetek wrote:
>>> [General]
>>> * Cleanup/Stabilize/Improve Documentation/Unit Tests at least part of
>>> the API A.K.A. "The ABI Normal Project"[1]
>>> * Move all non-stable classes to a KTp::priv namespace and build them as
>>> a separate library.
>>> * Install CMake files to find KTp
>>> * Qt5/KF5/C++11 porting
>>
>> Might be too soon for this^ for 0.7
>
> You mean just the Qt5/KF5/C++11 porting or all of the above items?
> Perhaps it is too early, but it's worth to investigate if there is
> something we need...
> For example we might need some hook in KApplication for KTp::Application[1].
>
>
> [1]https://community.kde.org/KTp/Tasks/ProperLibrary#TelepathyHandlerApplication
>
>
>
>>> * Make the chat widget a kpart
>>> * Make the contact list widget a kpart
>>
>> Do we have any actual use for these^ two or just "because it's cool"? ;)
>> (I'm all for it)
>
> Because it's cool! :D
> And of course, because when I play a DBusTube game I want to chat with
> my friend.
> For the contact list, I cannot think a real use case actually, I was
> thinking about a widget that shows the contacts in a group channel and
> that has the features of the contact list, including toolbar buttons, etc.
>
>
>
>> Can we make this one repo/package, something like ktp-tools? Currently
>> we are packagers' nightmare and I don't want to make their nightmares
>> any worse.
>
> Ok repo-packages requires some love (that obviously will cause hate on
> the packagers side).
>
> I'm not sure for packagers if it is easier to handle different several
> packages, but I think that a meta-package is the way to go...
>
>
> Anyway besides the meta-package, we have some grouping problems:
>
> There are different options:
> 1) group handlers and initiators (i.e. ktp-dialout-ui and ktp-call-ui)
> 2) keep them separates (i.e. ktp-filetransfer-handler and ktp-send-file)
> 3) initiator is a widget in ktp-common (i.e. join-chat-room and ktp-text-ui)
> 4) no initiator (started from some other place) (i.e. single chat)
>
> For example, at the moment the presence plasmoid checks if
> "ktp-dialout-ui" is installed, and if it is, it assumes that also the
> call ui is installed.
> This is not good for the filetransfer, because we have ft-handler and
> send-file in 2 separate repositories, and to be honest I'm happy with
> that. We should always check using the desktop files, and not the
> executable (one might install some other handler instead of the call ui
> and won't be able to start it).
>
> 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.

>
>
>>> [Playground]
>>> * Zeitgeist
>>
>> Needs full list of what we want to do with it and how. Seif is happy to
>> help us upstream.
>
> I put it in the "Playground" with the idea to "start playing with it",
> I'm sure we will come with several ideas as soon as we get acquainted it.
>
>
>
>
>>> * Web Accounts
>>
>> This^ requires a meeting with xclaessee and afiestas, anyone interested?
>> I'll set it up.
>
> What's the reason for the meeting? By the way, nobody ever told me what
> to do with the requirements we discussed at Akademy with the PIM people,
> I still have on my red book.
>
>
>
> Daniele
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy