I could live with this, but it's a bit hacky. What about putting a
hint in the buddy_icon_spec struct in the prpl_info that says "this
protocol only accepts buddy icons from here," rather than give an
error dialog specifying a path?

Also, how does this behave with the global buddy icon selector?
Perhaps that hint would remove the "use this buddy icon" checkbox and
always do its own thing with its own UI

My first inclination was to do something like that too. The problem is that in some cases (e.g., if the total amount of time the user has ever been online > X hours) the qq server allows the user to set a custom buddy icon. In that case, we want the buddy icon selector to behave exactly as it currently does.  Therefore, we need the prpl to check information it's received from the server and only in certain cases restrict the icon choice. I believe that a hint hard-coded into the icon_spec wouldn't allow that kind of flexibility.

Note that custom buddy icons aren't currently implemented (Last I checked, I hadn't met the server's qualifications yet, so I haven't been able to examine the protocol), but I wanted to ensure that when I am able to implement that feature, the current setup works. It is a bit hackish though, and I'm happy to rewrite the code if someone can find a better solution.

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.

As an aside, have you guys considered a gaim_buddy_icon_set/get_checksum() call? I was looking at how the other prpls handle buddy icons and there seems to be a bit of redundancy.

-Mark

-s.