Context Navigation

Ticket #2067 (closed patch: wontfix)

Opened 3 years ago

Last modified 16 months ago

Support for Animated GIFs (MSN, AIM, ICQ, YAHOO) Buddy Icons

Reported by:	praveenmarkandu	Owned by:
Milestone:		Component:	pidgin (gtk)
Version:	2.0.2	Keywords:
Cc:	Halan, frasten

Description

It would be nice if animated gifs were supported and users could see the animations in their buddy icons instead of a png

Attachments

add-animated-smileys-v0.5.patch (5.6 kB) - added by frasten 17 months ago.: Patch to add animated smileys

Change History

follow-up: ↓ 12 Changed 23 months ago by IlRazziatore

I read the comment ( and i post the comment about the Animated PNG ).

1] Read and save gif. You nead GTK write/read the file for you? Why? Pidgin can't use other library? If GTK can't sand message pidgin don't send message? Pidgin ins't a front end of GTK, GTK is only one of library Pidgin use. If GKT don't read/write GIF file okay you can use an other library or read/wirte file your-self.

Legaly you can't read the gif as image but no-one can say nothing to you if you semply read the byte and copy it.

When Pidgin recived an gif animated it display it, why not save it? You can't write a simply dump file rutine?

If you want i do it for you ( and i will do that myself but i don't understend wher put it in the pidgin source structure... )

You say isn't a Pidgin problem, I do not agree.

2] The animated emotions how are send? As File ( all the file in raw mode, with header ... ) or as an uncompressed animation?

If animated emotiocns are sand as raw file, you don't need decopress it you don't need "read" it. You don't need a library ( GTK ) read it for you. You nead only read the file ( and the file system do that for you ) and sand byte by byte the file.

If animated emoticons are sand as uncompressed animations... why don't use APNG localy?

3] You say "APNG wouldn't be all that useful anyway if other clients can't read them either".

I'm not agree again. I use Pidgin, my sister use Pidgin, a lot of my friend use Pidgin. Why we can't use APNG between us?

eMule extend the eDonkey protocol, at the begin no-one have eMule but this did not important. If two people had eMule they used the new feature otherwise no, patience. We don't must run after someone sometimes you can even overcome.

---

There are 3 tickets duplicate of this so the user want this features... You are always convinced that it isn't a Pidgin problem?

in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 23 months ago by datallah

Replying to IlRazziatore:

I read the comment ( and i post the comment about the Animated PNG ).

APNG isn't really relevant to this ticket. If you want to add support for APNG, the right place to do so is in gdk-pixbuf.

1] Read and save gif. You nead GTK write/read the file for you? Why? Pidgin can't use other library? If GTK can't sand message pidgin don't send message? Pidgin ins't a front end of GTK, GTK is only one of library Pidgin use. If GKT don't read/write GIF file okay you can use an other library or read/wirte file your-self.

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.

Legaly you can't read the gif as image but no-one can say nothing to you if you semply read the byte and copy it.

Actually, I don't think there are any more legal issues, it is just a matter of historical reasons that gdk-pixbuf doesn't support it, perhaps they would accept a patch to do so if it was reasonable.

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.

If you want i do it for you ( and i will do that myself but i don't understend wher put it in the pidgin source structure... )

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).

You say isn't a Pidgin problem, I do not agree. 2] The animated emotions how are send? As File ( all the file in raw mode, with header ... ) or as an uncompressed animation? If animated emotiocns are sand as raw file, you don't need decopress it you don't need "read" it. You don't need a library ( GTK ) read it for you. You nead only read the file ( and the file system do that for you ) and sand byte by byte the file. If animated emoticons are sand as uncompressed animations... why don't use APNG localy?

As I mentioned - if the gif you're trying to use doesn't need to be scaled (to fit the constraints of what the protocol accepts) to be sent, it will work as a buddy icon (this may not be the case for custom emoticons, I haven't tested it). If it does need to be scaled, then gdk-pixbuf needs to be able to do that for us to be able to send it.

3] You say "APNG wouldn't be all that useful anyway if other clients can't read them either". I'm not agree again. I use Pidgin, my sister use Pidgin, a lot of my friend use Pidgin. Why we can't use APNG between us? eMule extend the eDonkey protocol, at the begin no-one have eMule but this did not important. If two people had eMule they used the new feature otherwise no, patience.

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; we can't just send whatever we want. Perhaps for some protocols we could do this, but once again, we need gdk-pixbuf support.

There are 3 tickets duplicate of this so the user want this features... You are always convinced that it isn't a Pidgin problem?

Just because people don't like it doesn't mean it is a problem. As always, good patches that do something reasonable (adding a direct dependency to something like a gif library isn't something I would consider reasonable) are welcome.

in reply to: ↑ 12 ; follow-up: ↓ 14 Changed 23 months ago by IlRazziatore

Replying to 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?

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...

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?

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

If i have all this informations wirte a routine is a litle work...

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.

There are 3 tickets duplicate of this so the user want this features... You are always convinced that it isn't a Pidgin problem?

Just because people don't like it doesn't mean it is a problem.

I know my english isn't good and i know what i write isn't want i want to write. I try again.

As a programmer i can use two philosophies of life:

The programmer write the program for himself and if anyone uses it it's okay and if you anyone don't use, it's okay the same.

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.

I am vain? maybe.

Obviously no one can impose anything on anyone. I hope now I explained what i want to write even with my ( very ) bad English. ( And I apologize for my insistence )

in reply to: ↑ 13 Changed 23 months ago by datallah

Replying to IlRazziatore:

Replying to 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.

Changed 19 months ago by deryni

To reiterate what has been said here a number of times, the problem is that GTK+ (specifically the gdk-pixbuf library) does not supporting writing gif files, as such pidgin does not support it. The correct place to add support for writing gif files is in gdk-pixbuf, if you wish to submit a patch to the GTK+ people which adds support for this you should talk to them about it. Until then there are potential ways of working around this issue in pidgin which could be implemented if someone so desired (specifically copying from the raw image stored in the cache as opposed to writing the image out from the GdkPixbuf?), but again someone with the need for this feature would need to write the patch.

Changed 18 months ago by Ongion

Ok, a few questions here. 1. The location that you gave us for the cache is only for Buddy Icons. Is there a cache for animated emoticons and if so, where is it? 2. You say that GTK+ does not support writing gif files. That really doesn't factor into "how can we save animated emoticons?". That just tells us how we CAN'T. Libpurple still has to handle an image before it can be used as a GdkPifBuf? I'm pretty sure they images are stored on disk temporarily. If so, where? 3. You keep telling us that if we want to fix it, then we can. However, you aren't pointing us in the right direction. We don't know how the image-writing works. You claim to have explained it, yet you have not. Would it be that hard to say "the problem exists in X file"? And if we'd need to modify GTK+ (not that we would have to. See question two.), then that's even more of a reason to give us a starting point. GTK+ is kinda big.

All I'm asking for is a little help in the supposedly "easy" solutions you've said could be done. They're obviously not so "easy", as at least 5 different duplicates have been opened, and it remains unsolved.

Changed 18 months ago by deryni

1. From a quick look at the source it would appear to be ~/.purple/custom_smiley though that may or may not only be for locally created smileys. (And in fact from a slightly more in-depth look it appears like remote custom smileys may not be saved to disk at all.) Also this ticket is specifically about buddy icons and not smileys.

2. Correct, that indicates why we can't at the moment have it Just Work. It would appear (assuming I read things correctly) that in fact your surety would be misplaced. And direction as to how libpurple might be made to save them has in fact been presented, the idea would be to copy the file out of the cache rather than re-write the data from the GdkPixbuf? (which you know is the proposed "solution" since these questions pre-suppose that knowledge).

3. We have pointed you (collectively) in the right direction, that direction is to write a patch which copies the raw saved cache file instead of re-writing the GdkPixbuf? when someone attempts to save the icon locally (or much more appropriately, to fix the gdkpixbuf library to support writing animated gifs, though that is likely a much harder patch to write and will take longer to be effective). We have not explained how image writing works because pidgin and libpurple don't write images, we write raw data to the cache file and we trust GdkPixbuf? to do the right thing when we ask it to.

There isn't a simple "the problem is in file X at line Y" for this issue, as we've explained multiple times. But if you want to know where the buddy icon saving code is located you can find it by tracing the code that generates the Save menu entries. You can also try searching for "gdk_pixbuf_save" (which you could have found as a likely candidate for searching by looking at the gdk-pixbuf library reference documentation on library.gnome.org).

No one said you need to modify GTK+, what we have said is that the correct way to solve this problem is to update gdk-pixbuf to support writing gif images and specifically animated gifs. That was, is, and will remain the correct solution. And we are in no way capable of giving you more specific information as to where to look or what to do as we are not GTK+ (specifically gdk-pixbuf) developers and so have no inherent knowledge of the code of that library. You can look at the code as easily as we can.

The number of duplicate tickets opened on this issue has absolutely no bearing on how easy it may or may not be to work around the currently missing feature. Zero. What it mostly has bearing on is the difficulty most people have searching for existing tickets before posting new ones, a difficulty that is largely the fault of trac (though some fair amount of fault can be ascribed to the posters of the duplicate tickets) but this is an entirely irrelevant discussion at the moment.

If you want more specific help or have more specific questions feel free to join the #pidgin IRC channel or the devel@conference.pidgin.im XMPP MUC room and ask them, but don't feel like you can insinuate that we have not been helpful in indicating how this should be done because we have at every step of the way.

Changed 18 months ago by Ongion

I apologise for insinuating that the developers (and possibly specifically you) have been unhelpful. I was a little annoyed last night, and while I realise that this doesn't excuse me from anything, I realise that what I did was wrong.

Your last post has actually been very helpful to me. I had suspected that it was in the "custom_smiley" file, but I was not sure. Probably should have just asked. I think I'm going to see if I can fix it myself, but if I have any trouble I will be sure to ask on IRC. I also have a friend who probably knows a bit more about C than I do, so I can ask him.

Once again, I am very sorry. Thank you for the recent post, however.

Note: See TracTickets for help on using tickets.

Download in other formats:

Context Navigation

Ticket #2067 (closed patch: wontfix)

Support for Animated GIFs (MSN, AIM, ICQ, YAHOO) Buddy Icons

Description

Attachments

Change History

follow-up: ↓ 6 Changed 3 years ago by rez

Changed 3 years ago by datallah

Changed 23 months ago by datallah

Changed 23 months ago by datallah

Changed 23 months ago by IlRazziatore

in reply to: ↑ 1 Changed 23 months ago by IlRazziatore

Changed 23 months ago by QuLogic

Changed 23 months ago by IlRazziatore

Changed 23 months ago by IlRazziatore

Changed 23 months ago by datallah

follow-up: ↓ 12 Changed 23 months ago by IlRazziatore

in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 23 months ago by datallah

in reply to: ↑ 12 ; follow-up: ↓ 14 Changed 23 months ago by IlRazziatore

in reply to: ↑ 13 Changed 23 months ago by datallah

Changed 21 months ago by datallah

Changed 20 months ago by datallah

Changed 19 months ago by salinasv

Changed 19 months ago by PhobosK

Changed 19 months ago by deryni

Changed 18 months ago by Ongion

Changed 18 months ago by deryni

Changed 18 months ago by Ongion

follow-up: ↓ 24 Changed 17 months ago by Halan

in reply to: ↑ 23 Changed 17 months ago by datallah

Changed 17 months ago by frasten

Changed 17 months ago by frasten

Changed 16 months ago by datallah

Download in other formats: