Revision 6d1ef619baf3d738285880ef745ddd512d6e97bb

[Etan Reisner]

On Fri, Jun 22, 2007 at 03:12:10PM -0400, Evan Schoenberg wrote:
> The problem with notification via notify_info, and this isn't limited
> to the registration situation, is that it *requires* the UI to pop up
> a new window with the information; there's no context with which it
> could integrate the information into an existing window or display it
> differently (e.g. with a different icon).  The only alternative is to
> either put _all_ info notifications into a single place, such as a
> dedicated 'notification' window or the contact list, or to parse out
> the text of the notification to process it.
>
> I'm not saying that this particular notification should be integrated
> into some other window, though I could see the information being
> displayed in the account configuration dialog instead of in its own
> window.  This is, however, why I'd like to see many of the current
> 'generic' notify_info calls go through specific UI callbacks *or*
> carry with them some identifier (one not intended for display to
> humans and therefore not localized) so the UI could route the
> information to appropriate places.
>
> -Evan

Just to be clear, my intent with my comments on this topic has not been to
prevent moving registration information into a function, ui_op, and/or
signal. I just did not understand the implementation choice nor did I
understand the impetus behind the change at this moment.

I think making less ui assumptions from the core/prpl is a good thing and
see no problems with making the function/ui_op/signal for this. I just
wouldn't want to see it added and utilized for things it doesn't need to
used for.

	-Etan