[Pidgin] #6020: purple_xfer_get_remote_user should normalize returned user, fixes Adium issue with transfer on new tab

[Pidgin]

#6020: purple_xfer_get_remote_user should normalize returned user, fixes Adium
issue with transfer on new tab
------------------------+---------------------------------------------------
  Reporter:  ono        |       Owner:                
      Type:  patch      |      Status:  new           
  Priority:  minor      |   Milestone:                
 Component:  libpurple  |     Version:  2.4.2         
Resolution:             |    Keywords:  file, transfer
   Pending:  0          |  
------------------------+---------------------------------------------------
Comment (by ono):

 For front-end such as Adium or Pidgin? I believe never, only normalized
 values are valid user-ids, that's why all this mess. Most funny thing is
 that `purple_xfer_get_remote_user` isn't used at all in ''Pidgin'' and it
 is used once in ''Adium'' just to bind user with this fancy download
 button (see ''Adium'' bug report link above)

 adiumPurpleSignals.m:300:
 {{{
 fileTransfer = [accountLookup(xfer->account)
 newFileTransferObjectWith:[NSString
 stringWithUTF8String:purple_xfer_get_remote_user(xfer)]
 }}}

 While for other fields than `xfer->who`, ''Adium'' just access then
 directly:

 adiumPurpleRequest.m:399:
 {{{
 if (xfer->local_filename != NULL && xfer->filename != NULL) {
 }}}

 I've tried other way to fix the issue -> change just ''Jabber'' functions
 at:

 libpurple/protocols/jabber/si.c:1272:
 {{{
 xfer = purple_xfer_new(js->gc->account, PURPLE_XFER_RECEIVE, from);
 }}}

 So the `from` is normalized prior calling `purple_xfer_new`, but it seems
 that the FT is then getting broken, as resource id is not stored anymore
 in `xfer`, and it is needed/used by other FT routines.

 Therefore this fix is the only one that works for now :) (And it is just
 small change)

-- 
Ticket URL: <http://developer.pidgin.im/ticket/6020#comment:3>
Pidgin <http://pidgin.im>
Pidgin