palettes of buddies in the neighborhood don't update

[sascha_silbe]

How to reproduce:
1. Switch to neighborhood.
2. Right click on someone who isn't a "friend" yet.
3. Choose "Make friend".
4. Right click again on the same person.

Actual results:
The palette still shows "Make friend".

Expected results:
Show "Remove friend".

Even switching somewhere else and back to the neighborhood doesn't change the entry.

[walter]

I've confirmed this. It seems to be a regression.

[sascha_silbe]

A quick check of the source suggests that jarabe.view.buddymenu.BuddyMenu needs to listen to the friend-added and friend-removed signals of jarabe.model.friends.Friends.

[timclicks]

Looking at jarabe.view.buddymenu.BuddyMenu, there is already a check to see whether the person is a current friend. If the method is checking for the state every time and doesn't have its own list of buddies, does it need to listen to signals also?

This seems to be the relevant method:

def  _add_buddy_items(self):
    if friends.get_model().has_buddy(self._buddy):
        menu_item = MenuItem(_('Remove friend'), 'list-remove')
        menu_item.connect('activate', self._remove_friend_cb)
    else:
        menu_item = MenuItem(_('Make friend'), 'list-add')
        menu_item.connect('activate', self._make_friend_cb)

If this check isn't working, it could mean that jarabe.model.friends.get_model isn't working properly... I don't see a __call__() method in jarabe.model.friends.Friends, but I don't know enough about gobject.GObject to know if this is a problem.

_model =  None

def get_model():
    global _model
    if _model is None:
        _model = Friends()
    return _model

[bernie]

Replying to timclicks:

If this check isn't working, it could mean that jarabe.model.friends.get_model isn't working properly... I don't see a __call__() method in jarabe.model.friends.Friends, but I don't know enough about gobject.GObject to know if this is a problem.

{{{
#!python
_model = None

def get_model():
global _model
if _model is None:
_model = Friends()
return _model
}}}

get_model() implements a Singleton pattern. The first time you invoke it, it builds a Friends object through the constructor and stores a reference to it in the global variable _model, which is used in future calls.

[anurag_seeta]

What i noticed regarding this bug was that after adding a friend you will still get add friend option instead of remove friend , but once you restart your system then next time you will get remove friend option but any more subsequent changes will again have the same issues. So what i gather is there must be an issue with the entire refresh criterion which is done only on system restart, are there any set of files in sugar that update only on system restart and which could possibly be the reason behind this bug because if it would have been a codind error then even a system restart would not of have updated the pallete.

[anurag_seeta]

What I figured out for this bug is that the bug could be solved only if the shell service has a D-Bus API for buddies. Untill then even the present scenario of one time update during system restart has also been applied through a hack place in sync_friends () in the jarabe.model.friends.py module
this bug will get wrapped itself when the said api for shell service will get designed
then even this sync_friends function would be removed.

But I would need some pointers on how to create this dbus api for the present scenario and how will that work through the process to solve this defect.

[tomeu]

Why D-Bus? We have only one process involved, so there's no need for any IPC.

Sascha and Tim are right in their analysis, but the solution I would prefer is to make sure that the palette gets disposed when it pops down. That way, when it pops up again, it will check the current status of the buddy.

[tomeu]

This also affect other parts of the palette such as the nick name.

[alsroot]

I've set Severity to Blocker because commit (it is in 0.90.2)
 http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/356641c332d6cc889b265dfc29598004cf37763c
introduced a regression.

|TestCase|
* switch to journal
* open entry palette
* choose "Vew Details"
* nothing happened

The problem part is:

diff --git a/src/sugar/graphics/palettewindow.py b/src/sugar/graphics/palettewindow.py
index f51c938..449c77f 100644
--- a/src/sugar/graphics/palettewindow.py
+++ b/src/sugar/graphics/palettewindow.py
@@ -642,7 +642,6 @@ class Invoker(gobject.GObject):
         if self._palette is not None:
             self._palette.popdown(immediate=True)
             self._palette.props.invoker = None
-            self._palette.destroy()

         self._palette = palette

This is because on popdown, palette is being destroyed but Journal sends envet for Palette object, thus signal never be processed (maybe it works in some cases but I guess it is indeterminate behaviour).

In fact, it might be fixed in Journal but do we need destroy() call. afaik, gc will do this work but after that all signals will be delivered.

[alsroot]

Replying to alsroot:

I've set Severity to Blocker because commit (it is in 0.90.2)
 http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/356641c332d6cc889b265dfc29598004cf37763c
introduced a regression.

oops, it is
 http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/commits/29582de67f3189d232e170b1e07e9bf34233fb51

[erikos]

Sorry to be so late on this. Yes this is bad indeed. Another occurrence is, that you can not delete activities from the list view anymore. And yes the 'destroy' that Aleksey has been pointing out, is the issue. Need a closer look as to what is the appropriate fix here.

[erikos]

Fixed with:  http://git.sugarlabs.org/sugar-toolkit/mainline/commit/85e714ecb1e00e2652a6700a6868c698010c8c3e