On 11/30/06, Sean Egan <seanegan@...> wrote:
> On 11/30/06, Mark Huetsch <markhuetsch@...> wrote:
> > The current setup shouldn't cause any problems with the global buddy
> > selector. If you're using qq and oscar and try to set an icon that is
> > invalid in qq, you'll get the error notification and the qq prpl won't
> > change the icon but the oscar prpl still will. If that was your
> That was my question, but I see that as a problem; you shouldn't get
> an error dialog setting the global icon, I don't think. It should
> silently fail.
Oh. That makes sense.
Do you think it makes sense to implement it the way I described until
> the prpl supports custom buddy icons, and then changing it later?
I'll do this if you prefer, but it doesn't make a lot of sense to me. What
policy should I take once I have custom icons? I would have to remove the
hint from the icon_spec and then the same problem would occur. It would be
less of an issue if the vast majority of QQ accounts supported custom icons,
in which case such an error notification would be rare, but many or most
don't, so we'd pretty much be stuck in the same situation.
I suppose we could pass a flag to the set_buddy_icon_cb for each prpl,
indicating if the buddy icon selector was called globally or just on that
account. That would work, but it's hacky. If the primary concern is to keep
the noise level down, I could send the message to the debug log instead of
sending a notification. That's OK with me, but the slight problem in that
situation is that we're leaving the users to fend for themselves even in the
case where they are setting an invalid icon specifically for a single QQ
If gaim is going to undergo some sort of large change (GObjectification? I
don't understand that enough to know what new abilities it will give us)
that will render the above problem irrelevant after 2.0 and you're looking
for a quick fix, the icon_spec thing may be the way to go. Barring such a
change, IMO the flag hack would be the quicker and more flexible solution.