Building up to the 0.7 Release

[David Edmundson]

> https://bugs.kde.org/show_bug.cgi?id=324899
> https://bugs.kde.org/show_bug.cgi?id=324794
>
> I think these should be fixed before the beta, therefore I marked them
> for milestone 0.7-beta
>
The first is an assert I can turn off, it doesn't seem to harm
anything - but it's still wrong.
I don't understand it though. I clearly check inside libkpeople that
the index is valid, then it gets to my code and the index isn't
valid..

No idea on that second bug. I think it comes into the realm of
"QStandardItemModel is a bit naff".


>
>>> * Right click on a contact with several metacontact gives a HUGE list of
>>> actions, they should be grouped by account in submenus
>>
>> Yeah.. I'm not sure how to solve this at a technical level.
>>
>> KPeople builds up a list of QActions for a person.
>> I don't want to introduce QMenu code in there as that will screw over
>> other uses of this.
>> (in fact it's already a separate plugin system to separate UI from
>> Logic.. this being logic)
>>
>> I guess we could restrict it to just one "chat" action?
>>
>> For this code we need to think about the other potential usages of
>> kpeople, kmail etc. where we won't be showing a tree structure of
>> contacts.
>
> I don't like the idea of having just one "chat" action, even though
> there should be one entry for every supported action, and one submenu
> per account, i.e.
>
> contact
>  |- chat
>  |- foo
>  |- bar
>  |- account A
>  |   |- chat
>  |   |- foo
>  |- account B
>      |- chat
>      |- bar
>
>
> As I suggested David, KPeople could populate a list of QActions, but add
> some custom data to them (like the account they come from), then, the
> contact list, can use this data to sort/group actions...
>
>
Works here, but is it generic and portable?

If I  insert two actions
Chat
Chat using Foo at confused.com

For any other app not grouping per account that's made things worse.
and why would IM be grouped but not emails, phones, whatever else.

Martin, Apol any thoughts?

> Also I suggest to check if the nepomuk-telepathy-service is running, not
> the whole nepomuk.

Done. It should start it if it's not running too, which is nice.
Useful for people upgrading.

Not done the config check, it should be  a 2 line patch inside
KTp/core.cpp to read a config value
Any takers?

Adding a UI to set it might be more difficult.

>
> Is it possible to switch while ktp-contact-list is running? Or does it
> require different initialization, or similar?
>
No, I deemed that too complex - it's not just model switching but some
actions change, context menus too.
It might be possible, but to me far more effort than it's worth.
No-one toggle Nepomuk that regularly.

Long term there will be a PersonData constructor inside KTp::Contact
so it could get even more messy to try to do that.

>
> Another small non-blocking issue... From the person viewer, it looks
> like that the groups are duplicated instead of merged if a person has 2
> accounts and both accounts have a group with the same name. For example
> if person A has 2 accounts B and C both in a group D, the person viewer
> shows that the person is in groups D and D (even though he is not role
> player), I think that there should be a check to merge the groups with
> the same name, even if coming from 2 separate accounts.
>
Open a bug on libkpeople. PersonData should remove duplicates in al
the methods. It does not.

Probably not a beta blocking bug, but worth fixing.
>
>
> Thanks!
>
>
> Cheers,
>  Daniele
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy