Building up to the 0.7 Release

[Daniele E. Domenichelli]

Thanks for fixing most of the issues :)

Here's some more feedback after a few more days of usage!


On 11/09/13 19:18, David Edmundson wrote:
> On Wed, Sep 11, 2013 at 2:32 PM, Daniele E. Domenichelli
>> * Works! I don't get random crashes anymore! I can actually use the
>> contact list now! (awesome).
> 
> \o/
> 
>> * Sometimes it still crashes when I close the contact list (just
>> reported the bug).
> 
> /o\


After some more testing I still have two crashes, one at startup and one
when closing the contact list:

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



>> * I still have the multiple contacts problem (quite annoying).
> 
> I used to get that, I've not had that recently.
> I flushed my nco:contacts + pimo:persons two weeks  ago

I tried to flush my contacts and persons as well, and now my contact
list is completely empty, and I cannot get it to work again :(



>> * The "Show contacts by account" is confusing, I'm not sure if I see all
>> the metacontacts that have a contact that belong to that account,
>> sometimes I get contacts that do not belong to any account... Also if I
>> start a chat with a contact in this view, I'd expect to start a chat
>> with the relative account...
> 
> Yes, this is a problem.
> Right now in group by account mode we don't show any metacontacts as
> belonging to an account...
> Maybe in kpeople mode we can just have "no grouping" and "group by
> groups" rather than "group by accounts" and "group by groups".?

It looks better now, but the tooltip still shows "group contacts by
account. Anyway sometimes I'd like to be able to display the contacts
for one account... but I can live without it for now ;)



>> * 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...


>> * If KPeople was found at build time, there is no way to switch from the
>> old mode to the new one
>>
> I do (now) have a runtime switch in ktp-common-internals for if
> kpeople is enabled.
> 
> Right now it checks if nepomuk is running, it could check a config value too?


The config check would be good to force the non-kpeople version, at
least for the 0.7 version, it could be removed in 0.8. Many people have
nepomuk enabled, but might not want to test the beta version with
kpeople, therefore I believe it is necessary, and it should be either
disabled by default, or there should be a dialog to ask it the first
time it runs.
This should also influence whether X-KDE-Nepomuk-autostart for
nepomuk-telepathy-service is true or false, I don't know if this is
possible though.
Also I suggest to check if the nepomuk-telepathy-service is running, not
the whole nepomuk.

Is it possible to switch while ktp-contact-list is running? Or does it
require different initialization, or similar?


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.



Thanks!


Cheers,
 Daniele