> On July 5, 2013, 11:15 a.m., David Edmundson wrote:
> > main-widget.cpp, line 586
> > <http://git.reviewboard.kde.org/r/111387/diff/1/?file=168084#file168084line586>
> >
> >     I want this terminology consistent throughout libkpeople usage.
> >     
> >     In the Person app we use "merge".
> >     
> >     I like "link" too.. but I want it the same.
> 
> Martin Klapetek wrote:
>     Ok, I'll change the viewer to "Link" too.
> 
> Aleix Pol Gonzalez wrote:
>     We have also a merge dialog and a PersonDetails merge widget as well...
> 
> David Edmundson wrote:
>     [11:40] <mck182_> I think we should go with merge simply to keep 
> consistent
>
> 
> Martin Klapetek wrote:
>     I'll fix it all then. Next question - what should be the opposite? 
> Unmerge doesn't sound right...thoughts?
> 
> Thomas Pfeiffer wrote:
>     Separate?
> 
> Aleix Pol Gonzalez wrote:
>     "Create separate person"?
> 
> Martin Klapetek wrote:
>     Ok, I should specify this a bit more - the opposite action can happen in 
> two cases:
>      * single subcontact is selected (single contact is removed from 
> grounding occurances)
>      * whole person is selected (whole person is removed, contacts are all 
> separated)
>     
>     I'd like to have one single word/tooltip for these actions.
>     
>     "Separate" could work, any other ideas/suggestions?
>      Also we're not using "person" anywhere else, so I think we should try to 
> avoid that here too as the user has no idea of "persons".
> 
> Aleix Pol Gonzalez wrote:
>     Maybe we should? I think it's important to specify what's happening... 
> With split/separate we're talking about how the current state is going to be 
> destructed but it doesn't show how it will be restored.
>     
>     Said that, I guess "create person" could not be the best since we're not 
> creating persons per se ;).

Exactly, we're neither splitting nor creating persons. We're neither killers 
nor creators ;)


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111387/#review35628
-----------------------------------------------------------


On July 4, 2013, 10:49 a.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111387/
> -----------------------------------------------------------
> 
> (Updated July 4, 2013, 10:49 a.m.)
> 
> 
> Review request for Telepathy.
> 
> 
> Description
> -------
> 
> Adds KDualAction to merge contacts into a metacontact or unmerge 
> metacontacts. It still misses couple things (eg. getting the returned job and 
> then the uri of new created person), but it's quite complex and I'd like to 
> get early feedback on it.
> 
> There are many combinations that the user can select, main 9 ones (0 
> contacts, 1 contact, n contacts in combination with 0 persons, 1 person, n 
> persons) plus cases like "contact is a subcontact of selected person", 
> "contact is subcontact of different person" etc.
> 
> 
> Diffs
> -----
> 
>   contact-list-widget.h 0ab5449 
>   contact-list-widget.cpp 1bdf635 
>   main-widget.h 8dab6e0 
>   main-widget.cpp b9129fa 
> 
> Diff: http://git.reviewboard.kde.org/r/111387/diff/
> 
> 
> Testing
> -------
> 
> Selecting different contact combinations properly sets the KDualAction.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

_______________________________________________
KDE-Telepathy mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-telepathy

Reply via email to