On 11/30/06, Sean Egan <firstname.lastname@example.org> wrote:
On 11/30/06, Mark Huetsch <email@example.com> wrote:
> The current setup shouldn't cause any problems with the global buddy icon
> 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 question.
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
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 account.
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.