[Pidgin] #2067: Support for Animated GIFs (MSN, AIM, ICQ, YAHOO) Buddy Icons

Pidgin trac at pidgin.im
Tue Oct 21 20:01:11 EDT 2008


#2067: Support for Animated GIFs (MSN, AIM, ICQ, YAHOO) Buddy Icons
-----------------------------+----------------------------------------------
 Reporter:  praveenmarkandu  |        Owner:              
     Type:  task             |       Status:  closed      
Milestone:                   |    Component:  pidgin (gtk)
  Version:  2.0.2            |   Resolution:  wontfix     
 Keywords:                   |  
-----------------------------+----------------------------------------------

Comment(by datallah):

 Replying to [comment:13 IlRazziatore]:
 > Replying to [comment:12 datallah]:
 > > What is displayed in the IMHtml is a !GdkPixbuf - that is what is
 being saved, not the original file; consequently the library needs to
 support saving whatever format we would like it to save as. Of course it
 is theoretically possible to change how this works, but IMO it isn't worth
 complicating life just so you can save animated gifs from the IM buffer.
 >
 > I don't understend. You recived something from the server and you give
 it to the IMHtml, right? Why you can't get the embedded data and save it?
 If there is GIF save it as GIF, if there are not GIF save it as .DAT what
 is the problem of this way?

 This is pretty much what I proposed that you try to implement if you are
 interested.

 >
 > I'm sorry i don't undestand why a GUI libray ( GDK ) is important for
 the IM subsystem... I want to recived and sand animaed emoticons... I
 recived it and it okay, so i supose i can send it... why not?
 >
 >
 > Pidgin is only a frontend for libpurple. This is a libpurple problem.
 Libpurple can sand and recived personal emoticons, and i supose it can
 save it too. GTK is only a layer but is only a top layer to see ( and use
 ) all of it...

 This isn't at all an issue for libpurple, by the time libpurple is
 involved, the image is just a byte array.  This is a UI implementation
 issue as I mentioned earlier.

 > > > When Pidgin recived an gif animated it display it, why not save it?
 You can't write a simply dump file rutine?
 > >
 > > We actually do, incoming animated gifs will be stored in the icon
 cache in ~\.purple\icons.  Perhaps it would be reasonable to support
 copying the file from the cache, if present instead of saving the
 !GdkPixbuf that is displayed.
 >
 > So you save incoming gif! Is an start point.
 > When you can save it, you can save ( and load ) you can send it too.
 > If the problem is the IM window is a litel problem becouse you can send
 the emoticos and this is what the people want... Isn't important if I see
 the gif "freezed" the important is my contact see it correclty.
 >
 > But sincerly i don't understend. You can save and load gif. You can show
 gif ( when i recived it ) ... so exaclty what is the problem? Only the
 loader?

 As I said, Pidgin can send animated gifs as long as they don't need to be
 scaled - that pretty much sums up the situation.

 >
 > >
 > > If you feel like working on making the saving of images from the IM
 history copy the cached file as a preferred method of saving, I think such
 a patch would be accepted (assuming it is done correctly).
 > >
 >
 > Unfortunately I do not know the mechanisms by which messages are
 received, recognized, parsed and then once acknowledged that there is a
 content embeded within it, showed

 I've tried to explain this as best I can.  If it is important enough to
 you and you are capable of working on it, I'd be happy to try to answer
 any coding questions that come up while you're working on it.


 > > Your eMule analogy doesn't quite fit - in most cases, the server is
 involved and only certain image formats (and sizes of images) are
 supported by the IM protocol;
 >
 > I say that i don't know how the protocol work. If the protocol want only
 PNG and GIF... okay, but why don't send staticaly GIF "AS IS" may be use
 only recived GIF so you are sure that are ok.

 I don't know what you mean here, my previous comment that you're replying
 to was in relation to sending arbitrary APNGs.  At any rate, you seem to
 be confusing protocol constraints with implementation constraints.

 >
 > Then there is a second philosophy, that always write the program for me
 but I am happy if someone else uses it. And perhaps knowing that someone
 would use it but for a certain thing does not using it makes him sad.
 >
 > I'm in the second category, if I knew that a person does not use my
 program when maybe want to use it because there of a particular thing...
 it make me vary sad.

 And as I mentioned, reasonable patches are welcome.

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


More information about the Tracker mailing list