[PATCH] Add serv_got_private_alias
felipe.contreras at gmail.com
Sun Feb 24 17:28:09 EST 2008
On Sun, Feb 24, 2008 at 11:57 PM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> On Sun, Feb 24, 2008 at 09:24:47PM +0200, Felipe Contreras wrote:
> > > So here is an example patch to use the new serv_got_private_alias.
> > > Note that prpl->alias_buddy should also be renamed to
> > > set_private_alias or something like that.
> > >
> > > Best regards.
> > So?
> > Any chance of this getting applied?
> Funny that you should mention this; I was looking at it just a while
> ago. Currently the patch is failing to apply due to conflicts in
> oscar.c and server.c because the code has changed too much since 2.3.1.
> I was looking at merging it by hand, but I'm not comfortable touching
> oscar at all. Any chance I could convince you to resubmit the patch
> against current monotone? I have no objections to the patch, for the
I only sent the changes to other prpls because I was asked for
examples of this new API. I guess the only important part are the
changes in the core, the rest can be ignored, and actually I recommend
you to do that since I'm not familiar with that code.
> Out of curiosity, where would this alias stuff fit if we were to
> completely kill off server.c for 3.0.0? Some of it feels like a good
> fit for blist.[ch], but it might be confusing if we split some functions
> up because they seem like a better fit in, say, prpl.[ch] and their
> companion functions are in other files because they seem to fit best
I don't know how much are you planning to change things for the mythical 3.0.0.
If you kill server.c then part should go to blist (got_*_alias) and
part should go to prpl (set_*_buddy_alias).
If you also use GObjects then you will probably be passing around
buddy objects instead of char *. Then it might become clear that all
the buddy prpl functions don't make sense since each protocol can have
specific implementations for the buddy stuff:
purple_buddy_set_property (buddy, "private_alias", value);
g_object_set (buddy, "private_alias", value, NULL);
In this case "buddy" can be a PurpleBuddyMsn, or PurpleBuddyYahoo, etc.
Then "got_private_alias" becomes the GObject signal "private_alias_changed".
Of course, that's assuming the buddy stops being a TreeModel equivalent.
More information about the Devel