Building up to the 0.7 Release

[David Edmundson]

On Wed, Sep 11, 2013 at 2:32 PM, Daniele E. Domenichelli
<daniele.domenichelli at gmail.com> wrote:
> Hello,
>
> Sorry if I disappeared, but I was on holiday in the countryside with my
> family and no computers/mobile phones.
> I just managed to update everything a couple of days ago.
>
> On 10/09/13 13:38, David Edmundson wrote:
>> In general I'm now quite happy with it. I don't get the crashes - but
>> it definitely has some rough edges. I want to move this forward, but I
>> don't want to taint our stable software.
>>
>> I would _really_ appreciate feedback of how well libkpeople works for
>> you, and your opinions on how we take this.
>
> Some feedback here, I should probably report some of them as bug, but
> I'm very short in time at the moment, so please forgive me!
>
> * 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\

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

> * Sometimes I have a weird empty contact in a weird empty group/accout
> that disappears if I switch view to account/group and go back
> * Merge has some kind of weird issue, I cannot merge all my contacts by
> dragging and dropping them, because I keep getting new contacts, I don't
> know if it is related to the multiple contacts problem (i.e. nepomuk
> feeder creating new contacts) or because they are unmerged instead of
> merged. It would be really useful for testing purposes to be able to see
> the nepomuk resource url in the contact list tooltips (perhaps enabled
> by the same debug switch that enables the inspect menu item in the text ui)

> * I don't see a way to know telepathy-nepomuk-service status, but I
> believe that the user should be warned somehow when not running.

> * Contact list should allow multiple selection and have an action to
> merge contacts, drag and drop works but is not very intuitive

There is a patch for that, I'll merge it.

> * Contact list should allow one to unmerge contacts

and this.

> * If you expand and shrink a contact, you cannot expand it again until
> you click on another contact. Also to start a chat with a metacontact
> you have to click 4 times

Hopefully the latest review with the tree branches will fix that.

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

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


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

> Most of these problems are usability issues. Even though KPeople seems
> to be stable enough, I wouldn't recommend to the packagers to enable
> KPeople yet, as it will make the user experience, imho, a lot worse for
> the average user. Anyway, if we had a way to switch, or even 2 different
> executables for the contact list (both built from the same sources, one
> with KPeople enabled and one without), so that the user can choose
> whether to use kpeople or not, then I'd be ok with it, even in making it
> a required dependency

Maybe the config value would solve this too?