I told you it was a sticky mess ;-)
Whatever we do is going to need a full extended release cycle of
testing, because too many things in too many prpls are coded to work
around the broken ways things go now. For instance, jabber has
ReallyUglyHacks(TM) to get around being told about the group rename
before it happens. Ugh.
I'd like to see a patch that touches just the core first, so we can
tweak the hell out of it (we being those of us who know what goes on
with the respective prpls), and then we can update the prpls (same we as
above). Otherwise it's going to be a hackish job, and cause a lot of
On Wed, 2004-05-05 at 02:17, Felipe Contreras wrote:
> Hi all,
> Trying to change some blist code I started to look here and there and I
> found many things that brought me some ideas that I tought you'll probabl=
> like to know. Here are them.
> First of all I noticed prpl can't be able to know the group of a buddy wh=
> adding them with the add_buddies, since that function receives a GList of
> buddy names, so you can't know the real group from where they came from. =
> I tought to change all the char * to GaimBuddy * in add/rem buddy/buddies
> and faceprint agreed. While doing so I found that only remove_buddies
> required a group_name, which I tought it made no sense because in fact yo=
> probably could delete a group of buddies from different groups at the sam=
> time. Then I realized that remove_buddies is only called from rename_grou=
> but no protocol actually uses remove_buddies except oscar, in the case th=
> group alredy exists, because all the buddies should be moved to that
> existing group. It is also used in serv_rename_group in the case the prpl
> doesn't have the corresponding function. Since I wanted to get rid of all
> those char *, I wanted to get rid of the group_name sent to remove_buddie=
> which made sense since to me but I found something weird...
> I found that serv_add_buddies only add buddies without caring about the
> group, serv_rename_group removes buddies from the old group_name with
> serv_remove_buddies and then adds them to the new group with
> serv_add_buddies which will add them to no group at all! Since I changed
> things so serv_add_buddies now receives a list of (GaimBuddy *)'s instead
> of a list of (char *)'s then in theory the prpl's may know the group they
> come from. But the problem is that gaim_blist_rename_group changes the
> group name only after serv_rename_group is called. So the easiest solutio=
> would be to change the group name after serv_remove_buddies and before
> serv_add_buddies, which may happend inside the prpl as in oscar. That is =
> solution that I really don't like, since it's messing all kind of layers.
> Then I tryied to do what KingAnt says at his comment in add_buddy_cb in
> gtkblist.c. And then I found that gaim_blist_add_buddy is almost the last
> step in adding a buddy, the next one is updating the UI. So it made sense
> to me that prpl's use that function. So taking a deeper look at
> add_buddy_cb made me realize some things.
> Why does a UI callback function messes doing new groups, buddies,
> communicating with the server side and updating other parts of the UI as =
> the requested command was properly done?
> So I tought there should be a non UI function that does most of that mess=
> It should receive a buddy_name, a group_name and the buddy_alias. It shou=
> creat a temporal GaimBuddy and call with it serv_add_buddy, and suppose
> somebody elese waits the anwer of that request. The name probably would b=
> gaim_request_add_buddy and can be called from any UI part.
> Then comes the next part that will receive the buddy_name and group_name.=
> may be also the buddy_alias and will look for the temoray GaimBuddy and
> now actually add it to the blist and update other parts of the UI as the
> buddy icon and conversations. That function could be gaim_add_buddy or
> That sequence will make the user see things as they happend and will also
> clean out the code as different layers don't mess. I even think a prpl
> actually calls gaim_blist_remove_buddy before sending the add request and
> gaim_blist_add_buddy after it's truly completed.
> There are is lot of tricky stuff like what happends if the group to add
> doesn't exist? It's easy to add the group before adding the buddy, but ho=
> do you know when the server has actually added the group? So that arises =
> lot of imlementation problems, but I really think that making buddy list
> handling (and even more) assyncronous is the way to go... I really don't
> think there is such thing as a syncronous IM protocol.
> But what do you guys think?