> After looking at the patch, I have to say that yes, that is very simple. 
> Which 
> brings to question, do you need the granularity of each type of change? Or 
> would just one signal LIST_GROUP_UPDATE would be sufficient? In the patch, 
> you treat all types of changes as the same, so it seems that fine granularity 
> is not needed.
> 
> > I have made a patch for signalling from the daemon to plugins when groups
> > are being added, removed, renamed, or reordered. Since there is no good
> > group identification (as it was discussed with Anders in irc), plugins are
> > only able to tell what happened with groups but cannot tell which exact
> > group(s) the action was performed upon. This has to be discussed further.
> > Therefore, the daemon patch in attachment is pretty simple.
> 
> I missed this conversation on IRC. What exactly is needed?


I haven't had the time to look at the patch yet, but to answer the mail
above, yes we need granularity.
If we just get a big "something with the groups has changed"-signal the
only thing to do in the plugin is to reload the entire list. If we can
know what happened, only that group/user needs to be updated. At least
the way the contact list model in qt4-gui is implemented would benifit
from getting detailed signals.
What is needed is: which group changed and what changed (added,
removed,renamed,moved). I thing adding/removing contacts to/from groups
should be a signal for the contact but it could also be a group signal
if someone has a good argument for it.

I would also very much like to separate group id from group sorting
index. Since I haven't checked the patch yet I don't know if this is
included but it has been discussed on IRC so I'll mention it here if you
missed it.
Currently when groups are reordered, the group id's are changed and all
contacts in the moved groups are affected. Firstly this causes a lot of
updates on the contacts and secondly it's causes a race condition since
a plugin (or a dialog in a plugin) may hold a group id and try to use it
after the daemon has changed the meaning of that id. Without signals the
plugins will never be notified when this happens and may continue to
used wrong groups until the user notices the problem and requests a full
refresh. With signals the plugin must still be able to update any cached
values in the list, open dialogs etc.

/Anders

Reply via email to