Create PurplePerson.

Review Request #1838 — Created Sept. 25, 2022 and submitted

Information

pidgin/pidgin
default

Reviewers

This automatically manages the sorting of contacts and will report the highest
ranked one as the priority contact.

Ran the unit tests

Summary ID
Create PurplePerson.
This automatically manages the sorting of contacts and will report the highest ranked one as the priority contact.
6d1f75b68b5351c58e2f1a900e64a006356a168c
Description From Last Updated

I forgot that I forgot to finish the docs, I'll get to that tonight..

grimgrim

"after add all the contacts" add was supposed to be adding?

lifesfadedlifesfaded

priority

lifesfadedlifesfaded

priority

lifesfadedlifesfaded

Since

QuLogicQuLogic

user's Or maybe rewrite like purple_person_set_avatar

QuLogicQuLogic

Ref should actually go in the if; see /r/1836.

QuLogicQuLogic

Extra blank line.

QuLogicQuLogic

When you remove a contact from the person, it doesn't appear that these signal handlers are removed.

QuLogicQuLogic

But avatar is NULL, which is the same as not passing it, so it doesn't exactly confirm that this worked.

QuLogicQuLogic

const?

QuLogicQuLogic

Why no assert for the second contact?

QuLogicQuLogic

This was only for debugging, wasn't it?

QuLogicQuLogic

sorted_presence and sorted_contact are not unref'd.

QuLogicQuLogic

I think the contacts should only be sorted when removed is true to avoid unnecessary sorting. Also this causes unexpected …

ivanhoeivanhoe

Maybe skip this if nothing removed as well?

QuLogicQuLogic

This callback is not added to contact.

QuLogicQuLogic
grim
grim
  1. 
      
  2. I forgot that I forgot to finish the docs, I'll get to that tonight..

  3. 
      
lifesfaded
  1. 
      
  2. libpurple/tests/test_person.c (Diff revision 1)
     
     

    "after add all the contacts" add was supposed to be adding?

  3. libpurple/tests/test_person.c (Diff revision 1)
     
     

    priority

  4. libpurple/tests/test_person.c (Diff revision 1)
     
     

    priority

  5. 
      
grim
QuLogic
  1. 
      
  2. libpurple/purpleperson.h (Diff revision 2)
     
     
  3. libpurple/purpleperson.h (Diff revision 2)
     
     

    user's

    Or maybe rewrite like purple_person_set_avatar

  4. libpurple/purpleperson.c (Diff revision 2)
     
     

    Ref should actually go in the if; see /r/1836.

  5. libpurple/purpleperson.c (Diff revision 2)
     
     
     

    Extra blank line.

  6. libpurple/purpleperson.c (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
     

    When you remove a contact from the person, it doesn't appear that these signal handlers are removed.

  7. libpurple/tests/test_person.c (Diff revision 2)
     
     

    But avatar is NULL, which is the same as not passing it, so it doesn't exactly confirm that this worked.

  8. libpurple/tests/test_person.c (Diff revision 2)
     
     
  9. libpurple/tests/test_person.c (Diff revision 2)
     
     

    Why no assert for the second contact?

    1. I had some reason for this at the time that made sense.. but I don't recall, and the tests pass when I just turning this to an else.

  10. libpurple/tests/test_person.c (Diff revision 2)
     
     
     

    This was only for debugging, wasn't it?

  11. libpurple/tests/test_person.c (Diff revision 2)
     
     

    sorted_presence and sorted_contact are not unref'd.

  12. 
      
grim
ivanhoe
  1. 
      
  2. libpurple/purpleperson.c (Diff revision 3)
     
     

    I think the contacts should only be sorted when removed is true to avoid unnecessary sorting.

    Also this causes unexpected behaviour in my opinion when you consider following unit test where the wrong contact is tried to be removed:

    static void
    test_purple_person_no_remove(void) {
      PurpleAccount *account = NULL;
      PurpleContact *contact1 = NULL;
      PurpleContact *contact2 = NULL;
      PurplePerson *person1 = NULL;
      PurplePerson *person2 = NULL;
      gboolean person1_changed = FALSE;
      gboolean person2_changed = FALSE;
    
      account = purple_account_new("test", "test");
      contact1 = purple_contact_new(account, "user1");
      contact2 = purple_contact_new(account, "user2");
      person1 = purple_person_new();
      person2 = purple_person_new();
    
      purple_person_add_contact(person1, contact1);
      purple_person_add_contact(person2, contact2);
    
      g_signal_connect(person1, "items-changed",
                       G_CALLBACK(test_purple_person_items_changed_cb), &person1_changed);
      g_signal_connect(person2, "items-changed",
                       G_CALLBACK(test_purple_person_items_changed_cb), &person2_changed);
    
      g_assert_false(purple_person_remove_contact(person1, contact2));
      g_assert_false(person1_changed);
    
      g_clear_object(&person1);
      g_clear_object(&person2);
      g_clear_object(&account);
    }
    

    With the current code the second assertion fails.

    1. I agree that we should only sort if we removed something.

      That said, we can't exactly test for that, because the order shouldn't change. The items aren't picked randomly and if nothing else changes, they should sort in the same order regardless.

      Also, your example test doesn't need a second person, PurpleContact can and will exist outside of a PurplePerson.

  3. 
      
grim
QuLogic
  1. 
      
  2. libpurple/purpleperson.c (Diff revision 4)
     
     

    Maybe skip this if nothing removed as well?

  3. libpurple/purpleperson.c (Diff revision 4)
     
     
     

    This callback is not added to contact.

  4. 
      
grim
QuLogic
  1. Ship It!
  2. 
      
grim
Review request changed

Status: Closed (submitted)

Loading...