Send Custom Emoticons in MSN

[salinasv]

This is the update from the SF patch posted by gloomer months ago, I took the task to rewrite it and make all necessary changes to be useful with the MSNP14 branch, not at the main branch(as rlaager ask me to do) the patch was splitted with quilt to make things easy, you can only apply the patches one a time following the "series" file or simply adding the "patches" dir to your tree and doing $quilt push -a

I just finished it and seems to work I want to add some features like adding a received emoticon and display the "emoticon" in the manager (not only the text) but it only complicate things, I will do that later

as with the one in SF you need to add

<pref name='custom' type='string' value='custom_emoticons'/>  

to the <pref='smileys'> on the "purple section in prefs.xml

This is fully a RFC so if you have some problem or (better) a patch just tell me.

There was a reference ticket #100 where we talked about this

[salinasv]

The Patch

[Twain28]

Wonderful news!!!! I can finally switch to Pidgin (I was waiting for something like this to leave my old Gaim b6 patched with Glommer's old patch! Will test it as soon as I can (maybe waiting tomorrow Pidgin 2.0.1)! Thanks a lot, salinasv....I'll also wait for your future modifications....

[GothicAwakening]

I get this when applying to the current mtn checkout.

Hunk #16 FAILED at 4435. 1 out of 17 hunks FAILED -- saving rejects to file pidgin/gtkimhtml.c.rej

[GothicAwakening]

If I do a 'quilt refresh' then the patches all apply, but the custom emotions do not show up in the Smileys window as they did before.

[salinasv]

did you patched against MSNP14 branch ?? I have the last mnt revision of MSNP14 maybe you are patching against im.pidgin.pidgin

and be careful adding the pref in the "purple" section.. btw if you add this in a wrong way the debug log will tell you that "can't find /smiley/custom"

thanks for testing it

[GothicAwakening]

Yup, I just did the whole monotone thing again from scratch to make sure, I am using the im.pidgin.cpw.khc.msnp14 branch, when I do a quilt push -a I get:

Applying patch patches/custom_send.patch
patching file pidgin/gtkconv.c
Hunk #3 succeeded at 2045 (offset 6 lines).
Hunk #5 succeeded at 4075 (offset 12 lines).
Hunk #7 succeeded at 4427 (offset 12 lines).
Hunk #8 succeeded at 4722 (offset 14 lines).
Hunk #9 succeeded at 4738 (offset 12 lines).
Hunk #10 succeeded at 5034 (offset 14 lines).
Hunk #11 succeeded at 5177 (offset 12 lines).
Hunk #12 succeeded at 5388 (offset 14 lines).
Hunk #13 succeeded at 5684 (offset 12 lines).
Hunk #14 succeeded at 5728 (offset 14 lines).
Hunk #15 succeeded at 5735 (offset 12 lines).
Hunk #16 succeeded at 5748 (offset 14 lines).
Hunk #17 succeeded at 5765 (offset 12 lines).
Hunk #18 succeeded at 5787 (offset 14 lines).
Hunk #19 succeeded at 5935 (offset 12 lines).
Hunk #20 succeeded at 6060 (offset 14 lines).
patching file pidgin/gtkimhtml.c
Hunk #16 FAILED at 4435.
1 out of 17 hunks FAILED -- rejects in file pidgin/gtkimhtml.c

All the other patches apply fine.

[salinasv]

ok.. I just have not noticed the last propagation from im.pidgin.pidgin, there area changes in some of the patched files. I am updating the patch but seems to "not compile" I need to double check what happens, it will be uploaded here by nigth.

[salinasv]

This should work now

[salinasv]

Sorry for be late uploading the new patch but my monotone got problems with boost upgrading and I was unable to run mtn update and my working tree seems to be broke (...and you know my friends graduating and stuff) The "not compile" problems was caused by my corrupted working tree I don't know what happened there maybe I broke monotone when doing mtn update

But all of this stuff are fixed and have checked the patch. This one should work I just compile it.

thanks for testing the patch

[salinasv]

The last commits avoid this to be patched correctly, this one is update to 27/may.

[groovy]

when saving a received emoticon and it is an animated .gif, it gets convertet to (default) .png format and the animation is lost. are there plans saving the animation by using .gif file format? it also seems that added emoticons get lost when pidgin is closed. what is the place, where informations about added emoticons are stored? is there a way adding them offline by editing a config file? anyway, great work ;)

[GothicAwakening]

Patch applies fine, but none of my custom smileys show up in the Smileys window.. I have checked and the setting is in my purple section. Any ideas why it might not be working?

The only thing I can see in the log related to smileys is this:

(16:46:43) custom-smiley: imhtml_smiley_at_iter handles animated
(16:46:43) custom-smiley: imtml_smiley_at_iter animated done
(16:46:43) custom-smiley: imhtml_smiley_at_iter handles animated
(16:46:43) custom-smiley: imtml_smiley_at_iter animated done
(16:46:43) custom-smiley: imhtml_smiley_at_iter handles animated
(16:46:43) custom-smiley: imtml_smiley_at_iter animated done
(16:46:44) util: Writing file prefs.xml to directory /home/stephan/.purple

Those were all missing returns after them too (so it all ended up as one line).

When I run GAIM my custom smileys work fine.

[GothicAwakening]

Sorry, let me provide some further info.

The emoticons.txt list from the old patch seems to be totally ignored, none from that list are showing up.

When I add new smileys using the menu, they are there, but only until I restart Pidgin, when they all go away again.

[groovy]

Replying to GothicAwakening:

Sorry, let me provide some further info. The emoticons.txt list from the old patch seems to be totally ignored, none from that list are showing up.

emoticons.txt? is this the file where the settings about custom smileys are stored? such a file isn't found on my system. did i miss something? where is this file from?

When I add new smileys using the menu, they are there, but only until I restart Pidgin, when they all go away again.

yepp, same here: after restarting pidgin, all custom smileys are gone.

btw. i did more like the way this worked, when i only had to put the smileys in the right directory, without the need to add them all by hand.

[GothicAwakening]

emoticons.txt is the how the old patch stored it's list of custom smileys, does this patch still work the same way?

[salinasv]

There is no a configuration file the smileys are added directly from the files so, if you want to add smileys without the "manager" you only need to add it to the directory and will be loaded the next time you "enable" your account. With the manager your emoticons will be loaded when you click add, it's only other way to do the same ;)

Sorry for the "missing emoticons on restart" Originally the smiley tree is initialized when connecting I changed this to be loaded when enabling but seems that the function is not called when you start pidgin with your account enabled so, you must disable and then enable it again to load the smileys. I did this change because don't make sense that you need to be singed-on to be able to manage your smileys, I'm taking a look at the code to make this work properly.

groovy: The save incoming emoticons is not touched here but I will try to figure out how to make this feature work to add it to the custom tree. I don't know exactly how this feature works.

[GothicAwakening]

Today all my friends reported they could not see any of the emoticons I added using Pidgin.. I am going to switch back to gaim as this patch seems to be non-functional at the moment.

A couple of things I have noticed:

1) Fix sending (why can other MSN users not see the smileys?). 2) When a smiley is inserted it should show in the text edit box. 3) When adding from the menu, it should remember the last folder I added one from (at least for each session) as after every single icon added using this method I had to browse though all my folders again to get to where I had them.. very frustrating. 4) Also for the menu, it should remember which account was being added to. When I was adding to my MSN account, I had to re-select that for every icon added as it would always revert to my Yahoo account int he pull-down for some reason. 5) Icons need to be initialized when Pidgin is started.

Apart from that it looks like it has great potential, the ability to drop ions into the folder and have them show up in the list (without needing to go though the menu) is nice.

[salinasv]

Thanks for test this one I hope will be merged

1) Fix sending (why can other MSN users not see the smileys?).

Some friends reported the same and now is fixed, was a problem with the api change and I didn't noticed.

2) When a smiley is inserted it should show in the text edit box.

If you insert the smiley with the mouse it will be showed, if not, the text is parsed when the message is processed to be sent

3) When adding from the menu, it should remember the last folder I added one from (at least for each session) as after every single icon added using this method I had to browse though all my folders again to get to where I had them.. very frustrating.

I didn't fix this, I think is a gtk issue. Will take a look maybe I can do something (if someone here knows how, tell me)

4) Also for the menu, it should remember which account was being added to. When I was adding to my MSN account, I had to re-select that for every icon added as it would always revert to my Yahoo account int he pull-down for some reason.

Why not, added.

5) Icons need to be initialized when Pidgin is started.

I can't do that. I wanted to initialize it when the account is "enabled" but if you start pidgin with your account enabled I can't get the smileys initialized. So I changed to do it when the account was loaded, but there are problems of sync and the ui_ops are not initialized so I decided to return to the old "initialize when connecting" style until find some better way.

Changelog:

• The pref line is not needed now, the path is now hard coded. Is not needed to be able to change the smileys path so is not important. I did this in one try to initialize without the prefs loaded, then I like it.
• The Manager remember last account you added a smiley in the session.

[salinasv]

fixes, described in comment:16

[groovy]

i'm currently testing...and it works fine so far ;) the msn.patch doesn't get applied correctly with current msnp14 branch...it fails in patching the user.h file, so i did edit this one (adding 1 line of code) and it compiles fine.

[salinasv]

I forgot to do quilt refresh to add the "last account" stuff. This and some cleanup

[GothicAwakening]

This one seems to work great now, been running it for most of the day without any problems. Thanks for all your working in getting this patch up and running.

[rlaager]

Apparently I'm going to review something here.

[salinasv]

to apply clear with the last mtn, 5/jun

[salinasv]

rlaager, the patch is splitted and msn.patch is the only prpl specific, all the other patches are core/ui. So you review all and nosnilmot the msn.patch.

Happy review =P

[rlaager]

I'm reading the diff right now. I'm not going to test anything today. I'm just going to comment as I go. Some of these things may be incredibly trivial, knowing me. ;)

get_per_account.patch:

• I would prefer you use "mtn diff" to generate your patches. Even if you do it file-by-file to split functional changes, that'd be better for me.
• I don't like that pidgin_themes_get_proto_smileys() is doing custom smileys. That seems inconsistent with the name. Additionally, you've changed that function to being something that returns a GSList that the caller MUST NOT free with one that the caller MUST free. I haven't looked for callers of it to see if you've updated them, but I'd rather you did something else. Plus, this change (and adding the username parameter) would push us to 3.0.0, so that's another reason to change it.
• Adding a member (username) to GtkIMHtmlToolbar breaks ABI, so this would force us to 3.0.0. Can this change be avoided without hackery? If so, please do that. If it needs hackery, then I'd rather accept the patch as-is for 3.0.0 and backport it to 2.x with whatever hackery separately.

prpl.patch:

• needs a space after the comma in the prototype for del_smiley.

gtktoolbar.patch:

• Why are you doing this? Call g_slist_free(smileys) instead.

  +	while(smileys)
  +		smileys = g_slist_delete_link(smileys, smileys);
  

• The change to gtk_imthtmltoolbar_associate_smileys() breaks API/ABI compatibility as well. The same comments as above apply here. (Can you avoid it without hackery?)
• The changes at the end here belong in another file, if you're going for splitting. ;)

custom_send.patch:

• You have a few things like this: "gtk_imhtml_get_account_name(GtkIMHtml *imhtml){". Put the opening brace at the beginning of the next line.
• This is not necessary, as g_free() will check for NULL and return if it's NULL:

  +	if(imhtml->account_name)
  +		g_free(imhtml->account_name);
  

• Removing the sml argument from gtk_imhtml_associate_smiley(), et al., breaks API/ABI compatibility. You should leave the argument there (and ignore it), if that makes sense here. Then, the changes to remove it should be separated into another patch that we can apply for 3.0.0.
• +void pidgin_themes_smiley_themeize(GtkWidget *, gboolean custom); is another ABI breaker. Perhaps these changes are all unavailable, and we should just do this for 3.0.0?

gtk_account_ui_ops.patch:

• I would prefer that pidgin_account_custom_smiley_del() be named pidgin_account_delete_custom_smiley().
• Likewise for pidgin_account_custom_smiley_add().
• Do we do this (see below) everywhere? I think that you can assume purple_find_prpl() will always return something when you use the protocol_id member of an account.

  +	proto = purple_find_prpl(account->protocol_id);
  +	if(!proto)
  +		return;
  

• "for( iter..." doesn't need that space
• This leaks and the first line is unnecessary:

  +	directory = g_malloc(sizeof("custom_emoticons"));
  +	directory = g_strdup("custom_emoticons");
  

• You're missing spaces after commas other places, as well. Likewise for "){" at the end of a line.
• I'm not a big fan of "function (foo);" or "keyword(blah)". You use "if (" in a number of places.
• Your "Add custom smiley fail at Write %s\n" line... Why is Write caps?
• That entire section is indented too much.

account.patch:

• The comment about "the first element" doesn't make sense to me.
• I'm also confused about why that'd be a char **.
• Is it best to call the UI op for every single custom smiley there? Would it make more sense to pass it the entire list in one call?
• You call del_custom_smiley without checking if it's NULL. This will crash in other UIs, including those that worked fine before this patch.

man.patch:

• g_malloc0(sizeof(struct _smiley)); can be replaced with g_new0(struct _smiley);
• There's a TODO in here.
• You have #ifndef _GAIM_GTKSMILEY_H in gtksmiley.h. Obviously, that should be changed to not reference GAIM.

After you fix the above issues (many of which I realize are trivial and formatting related, I realize), I think you should do a read through of this patch and make sure every line, block, and function is polished. It's very important to read the diffs and make sure cruft hasn't slipped through from development.

I think it would also be a good idea (especially in terms of showing yourself what you've changed) if you were to do the entries in ChangeLog.API. You may find a command like this helpful (from the top of your pidgin checkout): mtn diff find -name "*.h"

Finally, is it really best to be passing a filename down to the prpl? (Note: It might be, I really don't know.) Did you consider using the PurpleStoredImage stuff at all?

[groovy]

it's been more than a month now without any news here. is there still progress on this? i'm working with a somewhat outdated version of pidgin and this patchset. it works fine so far. however, opening the emoticon list takes 100% cpu and lags a lot. also, if there are many emoticons, the list exceeds the dimensions of the desktop, so the list should have a scrollbar. great work anyway ;)

[GothicAwakening]

I've not been able to test this anymore as the MSNP14 branch always goes into an endless loop at startup, eventually taking 100% CPU. Can anyone tell what revision to check out that they are using and works?

[msfbrasil]

Hello there!!!

By now I'm using version 2.0.2 of Pidgin, and it seems to not allow custom emoticons sending.

If I am right, could someone please tell me whether this patch will be part of final Pidgin source release, and when (on which version) ?

Best regards, Mauro.

[groovy]

Replying to msfbrasil:

Hello there!!! By now I'm using version 2.0.2 of Pidgin, and it seems to not allow custom emoticons sending.

that's right. the patchset mentioned above is against the MSNP14 branch in the monotone repository. but as gothicawakening said, it doesn't seem to work with the actual checkout (didn't test this, though). so we have to wait for news from salinasv.

If I am right, could someone please tell me whether this patch will be part of final Pidgin source release, and when (on which version) ?

it will be in an official release, hopefully. but not, before the issues mentioned by rlaager are fixed, i guess.

Best regards, Mauro.

best regards

[groovy]

Replying to GothicAwakening:

I've not been able to test this anymore as the MSNP14 branch always goes into an endless loop at startup, eventually taking 100% CPU. Can anyone tell what revision to check out that they are using and works?

as of the latest comment by rlaager i stopped testing new checkouts. unfortunately i even don't have my last (working) checkout anymore, so i'm waiting for a sign...

[joolz]

I think 05c6323b8b18ceba86add2ad239fb24fc61dc469 is the latest working. (patches applying ok)

[groovy]

it seems, this project is dead...or is it a very deep sleep only? pidgin 2.1.0 is out and i really like to use both, 2.1.0 _and_ this patch. any chance? is someone even working on the patch anymore?

[GothicAwakening]

With some changes the patch can be applied to the current MTN MSNP14 source, and seems to work well.

[salinasv]

Sorry all you guys I was on vacations since rlaager sent his review, without internet, computers, out of my home, traveling arround México =)

I just returned and have more than 100 emails in my inbox and stuff, the monday I start the school but I hope I will have time to update/review/correct the patch.

I don't remember very well all the details but, because of some API stuff I think this patch will not be merged to HEAD until 3.0.0 but I have to double check if I can change that API stuff before the MSNP14 merge.

Replying to GothicAwakening:

With some changes the patch can be applied to the current MTN MSNP14 source, and seems to work well.

It will be great if you can tell me the changes you did, because at this point I do not have idea what changed in the time I was out.

Regards

[groovy]

welcome back then, hope you had a good time :) of course i'm too interested in the changes GothicAwakening? made ;)

[brunogti]

in pidgin 2.1.0 the patch not work

:)

[GothicAwakening]

Attached is a working set of patch. I only changed the stuff that prevented it from patching, didn't fix the line numbers or anything else.. I take no responsibility if it doesn't work!

Please note that I have not done any changes to the programming, so I have not fixed any of the issued rlaager brought up, which maybe the original programmer could look at, sadly I have zero experience with GTK programming and no idea how everything works in Pidgin.. sorry.

This group of patches should work with todays MTN code, I just tested it. So far I have had no problems related to these patches, and have been using them for some time. It would be great to see them cleaned up and incorporated into the branch, I think this is a great feature to be included when the MSNP14 branch is merged back into the main one.

[GothicAwakening]

Patches that work with MTN on 2007-08-16 (based on Updated 2)

[brunogti]

msn.patch error

patching file libpurple/protocols/msn/msn.c
Hunk #3 succeeded at 689 (offset -95 lines).
Hunk #4 succeeded at 799 (offset -95 lines).
Hunk #5 FAILED at 858.
Hunk #6 FAILED at 895.
Hunk #7 FAILED at 911.
Hunk #8 succeeded at 2221 (offset -117 lines).
3 out of 8 hunks FAILED -- saving rejects to file libpurple/protocols/msn/msn.c.rej
patching file libpurple/protocols/msn/object.c
patching file libpurple/protocols/msn/user.c
Hunk #1 succeeded at 38 (offset -1 lines).
Hunk #2 succeeded at 159 with fuzz 1 (offset -67 lines).
patching file libpurple/protocols/msn/object.h
patching file libpurple/protocols/msn/slp.c
Hunk #1 succeeded at 276 (offset -2 lines).
Hunk #2 succeeded at 824 (offset -2 lines).
patching file libpurple/protocols/msn/user.h
Hunk #1 FAILED at 83.
1 out of 1 hunk FAILED -- saving rejects to file libpurple/protocols/msn/user.h.rej

[GothicAwakening]

Are you using the MSNP14 branch, with the current MTN source, then applying the patches with quilt?

quilt push -a

I just did a fresh MTN pull and tested it, still patches ok (lots of offsets and a couple of fuzzies, but works fine).

[GothicAwakening]

Eeek, I just realized there is in-fact a later version of the patches then the ones I cleaned up, I used patches_updated_02.tar.gz because it was already sitting in my directory, forgot to check for a newer one, been using that for ages.

So if you see any regressions that were fixed in updated3, its for that reason, sorry!

[tobi]

I just tested the patch, everything works fine besides the fact that the smileys do not appear in the recipient's chat window. Is there some obvious thing which I am missing?

[tobi]

disregard the last note, everything works now

[Twain28]

Can someone please point the last working revision number for this patch? MTN on 2007-08-16 is said on the latest patch entry....but:

patch applies to d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b (16 days ago), yet compiler crashes (will try to reproduce the errors and post them.

patch applies to dd6bb3a7d349ba0a9fe8cea9698aea8227a95658 (34 days ago), yet compiler crashes with

Creating library file:pidgin.dll.a
gtkblist.o : In function 'gtk_blist_menu_sendfile_cb':C:/cygwin/home/Twain_28/test/pidgin/gtkblist.c:304: undefined reference to 'pidgin_smiley_manager_show'
collect2:ld returned 1 exit status
make[1] *** [pidgin.dll] Error 1
make[1] Leaving directory '/home/Twain_28/test/pidgin'
make *** [all] Error 2

Any chance of an updated patch for the current MSNP14 branch, or to have the number of revision which this should apply and compile correctly? Thanks.

[salinasv]

Sorry. I have been very bussy this days with school and somehow in the development of MSNP14 the patch was broken. Here I have a fixed version of the patch (with this I mean, working again) but I find some bugs that I want to fix before updloading a new version of the patch.

Wait some days, I guess MSNP14 will be merged to pidgin the next week, hope I could get some time to find an fix this bugs and finish cleaning up the rlaager points of the review this weekend.

Twain28:
to fix your problem, make sure you have added the "gtksmiley.[hc]" to /pidgin/

Thanks for testing, if you find some other bug in the patch, please tell me about

[Twain28]

Replying to salinasv:

Twain28:
to fix your problem, make sure you have added the "gtksmiley.[hc]" to /pidgin/

I did, and I recompiled from start, yet nothing's changed: same error....I'm no coder, but I believe it might be some lack of reference to one of "gtkblist.c"'s functions....probably the line

{ N_("/Tools/Smile_y"), "<CTL>Y", pidgin_smiley_manager_show, 0, "<StockItem>", PIDGIN_STOCK_TOOLBAR_SMILEY },

, added by the "man.patch" has something to do with it.... Take a look at it, if you have some spare time. If not, don't worry: I'll wait for MSNP14 implementation....

[salinasv]

Replying to Twain28:

Replying to salinasv:

Twain28:
to fix your problem, make sure you have added the "gtksmiley.[hc]" to /pidgin/

I did, and I recompiled from start, yet nothing's changed: same error....I'm no coder, but I believe it might be some lack of reference to one of "gtkblist.c"'s functions....probably the line

 { N_("/Tools/Smile_y"), "<CTL>Y", pidgin_smiley_manager_show, 0, "<StockItem>", PIDGIN_STOCK_TOOLBAR_SMILEY },

, added by the "man.patch" has something to do with it....

Yes man.patch add this line and

+ #include gtksmiley.h

at the top of the file, maybe you have not this one.

If you have the gtksmiley.[ch] on your pidgin dir and the #include correctly I don't know what can cause the problem.

Please wait until the weekend and I will post a reviewed patch

Take a look at it, if you have some spare time. If not, don't worry: I'll wait for MSNP14 implementation....

[Twain28]

Replying to salinasv:

Yes man.patch add this line and

 + #include gtksmiley.h

at the top of the file, maybe you have not this one. If you have the gtksmiley.[ch] on your pidgin dir and the #include correctly I don't know what can cause the problem.

I do have them correctly placed (both files and both entries in the gtkblist.c. So, if it's not some cygwin problem, it seems I came across a bug....wohoo!

Please wait until the weekend and I will post a reviewed patch

I'll surely do. Thanks for your time....

[rlaager]

Any news on this?

[salinasv]

I'm having problems with the msn server, so I can't connect my account over msnp14 so I can't test the changes I just made.

Hope MS fix they servers or find the problem

[Twain28]

Replying to salinasv:

I'm having problems with the msn server, so I can't connect my account over msnp14 so I can't test the changes I just made. Hope MS fix they servers or find the problem

We're all waiting for that moment....you updated the patches to work against latest MSNP branch?

[Twain28]

With a few modifications, the patch seems to apply perfectly to latest MSNP14 branch in MTN....only thing that stops its flawless compilation is that

{ N_("/Tools/Smile_y"), "<CTL>Y", pidgin_smiley_manager_show, 0, "<StockItem>", PIDGIN_STOCK_TOOLBAR_SMILEY },

line, which, I'm afraid, is probably the core line for the sending function....commenting it shuts away gtksmiley.h and gtksmiley.c files....thus, Pidgin compiles and works (you can even see the custom smileys among those to choose from), yet sending does not work (buddies can't see the custom smiley, so I guess it's not being sent at all).

[Twain28]

Brief update: any news out there, Salinasv? It seems to me the sending's not working at all: I solved (thanks to Phil!) the broken referral above said. A simple line adding the 'gtksmiley.c' file to the Makefile.mingw solves compiling issues in Windows (seems the man.patch cared only about Linux's Makefile.am). Yet, still I can't send the smileys (same as above: everyone can see only the filename of my smiley) and, moreover, I noticed removing the custom smiley from its stock toolbar menu causes a crash. Has anyone got time to update this, please?

[Twain28]

Hoping someone notices all this, I continue to post updates: anyone who wants this patch to work should apply it to revision

225df0e615bb2eeed8c7af88c770ade3d78626fb , dated 8 August , 
compiled using Cywgwin with gtkspell-2.0.6 and silc-toolkit-1.0.2

the latest revision of that day also works, but lacks the try icon (matter solved in later builds). Also, the patch is quite unstable even then: closing Pidgin chashes with

pidgin.exe caused an Access Violation at location 6b8892b2 in module libmsn.dll Reading from location 0000001c.

Registers:
eax=00000000 ebx=02018a80 ecx=00c20050 edx=00ca9338 esi=02311f38 edi=6b8a1080
eip=6b8892b2 esp=0023e9e0 ebp=0023e9f8 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00200202

Call stack:
6B8892B2  libmsn.dll:6B8892B2  msn_del_smiley  msn.c:779
static void msn_del_smiley(
    PurpleConnection * pc = &{
        PurplePlugin * prpl = ,
        PurpleConnectionFlags flags = ,
        PurpleConnectionState state = ,
        PurpleAccount * account = ,
        char * password = ,
        int inpa = ,
        GSList * buddy_chats = ,
        void * proto_data = ,
        char * display_name = ,
        guint keepalive = ,
        gboolean wants_to_die = ,
        guint disconnect_timeout =
    },
    const char * smile = &'z'
)
    ...
    msn_del_smiley(PurpleConnection *pc, const char *smile)
    {
>    MsnSession *session = pc->proto_data;
    MsnUser *user = session->user;
    GSList *emoticons = user->emoticons;
    ...

64A471D3  pidgin.dll:64A471D3  pidgin_account_del_from_smiley_list  gtkaccount.c:2708
static void pidgin_account_del_from_smiley_list(
    PurpleAccount * account = &(indirect),
    const char * smile = &'z'
)
    ...
    account->custom_smileys = g_slist_remove(account->custom_smileys, smiley);
    if(prpl_info && prpl_info->del_smiley)
>    prpl_info->del_smiley(account->gc, smile);
   
    destroy_smiley(smiley);
    ...

67CC344E  libpurple.dll:67CC344E  purple_account_disconnect  account.c:1107
void purple_account_disconnect(
    PurpleAccount * account = &(indirect)
)
    ...
    /* Note that it forces the smile name to be the first element
     * of the struct */
>    ui_ops->del_custom_smiley(account, *(char **)smileys->data);
    }
    }
    ...

67CD37FC  libpurple.dll:67CD37FC  purple_connections_disconnect_all  connection.c:465
void purple_connections_disconnect_all(
   
)
    ...
    gc = l->data;
    gc->wants_to_die = TRUE;
>    purple_account_disconnect(gc->account);
    }
    }
    ...

67CD8B7C  libpurple.dll:67CD8B7C  purple_core_quit  core.c:186
void purple_core_quit(
   
)
    ...
   
    /* Save .xml files, remove signals, etc. */
>    purple_idle_uninit();
    purple_ssl_uninit();
    purple_pounces_uninit();
    ...

62743935  libgobject-2.0-0.dll:62743935  g_closure_invoke
62756FB5  libgobject-2.0-0.dll:62756FB5  g_signal_has_handler_pending
62757D5E  libgobject-2.0-0.dll:62757D5E  g_signal_emit_valist
62757FD6  libgobject-2.0-0.dll:62757FD6  g_signal_emit
6069C2A5  libgtk-win32-2.0-0.dll:6069C2A5  gtk_widget_activate
6058C71C  libgtk-win32-2.0-0.dll:6058C71C  gtk_menu_shell_activate_item
6058CA25  libgtk-win32-2.0-0.dll:6058CA25  gtk_menu_shell_activate_item
60578E62  libgtk-win32-2.0-0.dll:60578E62  gtk_marshal_VOID__UINT_STRING
62743935  libgobject-2.0-0.dll:62743935  g_closure_invoke
62756BE6  libgobject-2.0-0.dll:62756BE6  g_signal_has_handler_pending
62757ABC  libgobject-2.0-0.dll:62757ABC  g_signal_emit_valist
62757FD6  libgobject-2.0-0.dll:62757FD6  g_signal_emit
6069C434  libgtk-win32-2.0-0.dll:6069C434  gtk_widget_activate
60576011  libgtk-win32-2.0-0.dll:60576011  gtk_propagate_event
605772FD  libgtk-win32-2.0-0.dll:605772FD  gtk_main_do_event
6B070C5E  libgdk-win32-2.0-0.dll:6B070C5E  gdk_event_get_graphics_expose
672DEA67  libglib-2.0-0.dll:672DEA67  g_main_context_dispatch
672DFF3B  libglib-2.0-0.dll:672DFF3B  g_main_context_acquire
672E011A  libglib-2.0-0.dll:672E011A  g_main_loop_run
6057686E  libgtk-win32-2.0-0.dll:6057686E  gtk_main
64A891F7  pidgin.dll:64A891F7  pidgin_main  gtkmain.c:884
int pidgin_main(
    HINSTANCE hint = &{
        int i = 9460301
    },
    int argc = 1,
    char * * argv = &0x00032439
)
    ...
   
    #ifdef _WIN32
>    winpidgin_cleanup();
    #endif
   
    ...

0040209B  pidgin.exe:0040209B  WinMain  winpidgin.c:638
int WinMain(
    struct HINSTANCE__ * hInstance = &{
        int i = 9460301
    },
    struct HINSTANCE__ * hPrevInstance = &{
        int i =
    },
    char * lpszCmdLine = "",
    int nCmdShow = 1
)
    ...
    }
   
>    return pidgin_main(hInstance, __argc, __argv);
    }
   
    ...

0040249A  pidgin.exe:0040249A  WinMain  winpidgin.c:246
int WinMain(
    struct HINSTANCE__ * hInstance = &{
        int i =
    },
    struct HINSTANCE__ * hPrevInstance = &{
        int i = 205881
    },
    char * lpszCmdLine = &'À',
    int nCmdShow = 4214784
)
    ...
    if (!read_reg_string(hkey, "SOFTWARE\\GTK\\2.0", "Path",
    (LPBYTE) &gtkpath, &plen)) {
>    printf("GTK+ Path Registry Key not found. "
    "Assuming GTK+ is in the PATH.\n");
    return;
    ...

00401247  pidgin.exe:00401247
004012B8  pidgin.exe:004012B8
7C816FD7  kernel32.dll:7C816FD7  RegisterWaitForInputIdle

Applying the patches to any other revision from that day on works with some adjustments and compiles fine, but the sending won't work: buddies will only recieve the name of the custom smiley. Some updates, please, anyone???

[salinasv]

Thanks a lot for that bt, I guess that is the bug I was looking for to fix.

The patch should be ready to 3.0.0, it will not be applied in a earlier version, because it adds API, I need to sleep a little more and then try to merge my local branch without breaking anything, then I will upload the updated patch

Btw, I can't promise you to have it ready this week, I have a lot of work in my school, but I will try.

[Twain28]

Replying to salinasv:

Thanks a lot for that bt, I guess that is the bug I was looking for to fix.

One small step for a man, one giant leap for Salinasv: it's always a pleasure to give some small help.

The patch should be ready to 3.0.0, it will not be applied in a earlier version, because it adds API, I need to sleep a little more and then try to merge my local branch without breaking anything, then I will upload the updated patch Btw, I can't promise you to have it ready this week, I have a lot of work in my school, but I will try.

Many thanks, I'm really looking forward to see it, but don't overdo yourself: we need you healthy and coding. :) (in the meantime, crash apart, the patched rev works fine)

[Twain28]

Another update, 3 weeks after the last one: tweaking a little, this bunch of patches can be applied even to latest MTN revisions (now even to main branch ones @ im.pidgin.pidgin). The crashing with disconnect/close signal can also be avoided changing the order of a few lines (many thanks to Phil for looking this through). Still, even applying the patches correctly, you won't be able to send the smileys: buddy will see only "nameofsmileyimage.extension" words...Has this something to do with MSN SOAP changes? If so, should this patch modify something also in the SOAP part of Pidgin's code? (tricky business, this MSNP14!) Any news about updated versions of this patch?

[salinasv]

Thanks for updating

I have noticed the same problem but didn't find why it hapends. What I did to fix it was to apply the patch to an old revision and start propagating, but, you know, I'm not very good in this 3way merging and always get problems.

My computer was broke but I just fixed it, when I get my home stable I will take a look to your patch and try to fix my last merge, maybe we can get it working soon.

[Twain28]

applies correctly to latest MTNs, yet sending doesn't work

[Twain28]

Added the bigfile....can't seem to get the hang of splitting patches, sorry, salinasv. Another thing I want to suggest is taking a look at http://developer.pidgin.im/viewmtn/revision/diff/dd6bb3a7d349ba0a9fe8cea9698aea8227a95658/with/d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b the automated diff between the latest revision to which your patches applied and worked fine (dd6bb3a7d349ba0a9fe8cea9698aea8227a95658) and the next one (d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b), from which they stopped working.

[salinasv]

Oh thanks, now I can know who to blame about breaking the patch =P

I will take a look at it.

[rlaager]

You should put this patch in a branch in Monotone. See the UsingPidginMonotone branch if necessary. Get a checkout of the last version the patch worked on like this:

mtn -d $DATABASE checkout -r dd6bb3a7d349ba0a9fe8cea9698aea8227a95658

Then, apply the patch. Next, commit it as a branch (in the same namespace as similar things): mtn commit -b im.pidgin.cpw.khc.msnp14.ticket1187

After that, merge up to the next revision (where it's broken): mtn explicit_merge d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b h:im.pidgin.cpw.khc.msnp14.ticket1187 im.pidgin.cpw.khc.msnp14.ticket1187

Then, make it work and commit your changes. After that: mtn propagate im.pidgin.pidgin im.pidgin.cpw.khc.msnp14.ticket1187

Then you'll be merged up with head and hopefully it'll still work. If not, fix it and commit your changes. Then let me (or another developer) know and we can pull the changes from you and push them into our central repository.

[Twain28]

Replying to rlaager:

You should put this patch in a branch in Monotone. See the UsingPidginMonotone branch if necessary.

As Salinasv seems quite busy, I thought I could try this myself at home, using the huge mtn database supplied in the page suggested.

Get a checkout of the last version the patch worked on like this: mtn -d $DATABASE checkout -r dd6bb3a7d349ba0a9fe8cea9698aea8227a95658 Then, apply the patch.

Done.

Next, commit it as a branch (in the same namespace as similar things): mtn commit -b im.pidgin.cpw.khc.msnp14.ticket1187

Dealing with a local mtn database, I did :

mtn -d pidgin.mtn --branch=im.pidgin.cpw.khc.msnp14.ticket1187 setup 

then put all files to add to the branch in the same directory as the database file and

mtn add . -R 

then I committed everything to the local database with

mtn -d pidgin.mtn commit --message='try'

I tried checking out the new branch thus obtained, and all was well, so I went on

merge up to the next revision (where it's broken): mtn explicit_merge d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b h:im.pidgin.cpw.khc.msnp14.ticket1187 im.pidgin.cpw.khc.msnp14.ticket1187

that was, for me

mtn -d pidgin.mtn explicit_merge d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b h:im.pidgin.cpw.khc.msnp14.ticket1187 im.pidgin.cpw.khc.msnp14.ticket1187

and returns me the following:

expanding selection h:im.pidgin.cpw.khc.msnp14.ticket1187
expanded in 929db41c0cad0600c57da6da67425e537e462d0c
mtn [left] d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b
mtn [right] 929db41c0cad0600c57da6da67425e537e462d0c
mtn warning: rename target conflicts: nodes 7371, 676 both wanted parent 0, name
mtn warning: resolve non-content conflicts and then try again.
merge failed due to unresolved conflicts

Is that something I did wrong?

[Twain28]

Another non working patchfile

[Twain28]

Ok, following precisely the instructions above posted by rlaager I managed to do the first merge: I tested it, and sending custom smiley still worked. However, the second merge operation required me to setup a 3-way merge program (I'm under Windows)....so, being at a complete loss, I decided simply to make a diff between d42c2c6500b8f7eb1ad6340caf7f1b95d9b02c1b and its patched version. Obviously, applying it to newest im.pidgin.pidgin branches won't produce working code, yet I post it here, so anyone might take a look and maybe spot where actually the flow is. IMHO, since I saw the API is changed inside prpl.h file, I believe the purplereserved modifications this patch does might have something to do with this issue....there are no more 2 purplereserved spots to substitute in latest revisions, only one is left. Is that so, or am I completely mistaken?

[salinasv]

I tried that with the revisions you told me and didn't work, so I needed to go back to a july revision. I will try again this night.

Twain28, I'm on #pidgin as Masca, maybe you can join it to look if we can get it working this weekend ;)

[rlaager]

Twain28: You need to setup a 3-way merge program and do an actual merge. That's really the heart of what needs to be done here.

And yes, we've since used some of the reserved pointers for other things. The merge should be pretty straightforward if you weren't using one of them. If you were, catch someone on IRC and we can talk about.

salinasv: If you want to work on this, I'm around today. Start by following my instructions from earlier and then carry on as I've mentioned in this posting.

[msfbrasil]

Hello there!

Does anyone have any idea of when this effort will be reinitiated and mainly, when this feature will be available on main Pidgin branch and tarball file?

By the way, I'm trying to get this working with the revision I have here and already noticed a problem. It seems "msn.c" and "prpl.h" are using incompatible PurplePluginProtocolInfo? structures.

Best regards!!!!

[msfbrasil]

Sorry guys...

Please disconsider the note about "PurplePluginProtocolInfo?" structures. I messed up things here. :-(

[Twain28]

works with rev. 6c4e49ad8170ba8cd03804beff820107a11db58b (im.pidgin.pidgin 19 Nov)

[Twain28]

Just to give an update, here's another big patchfile....here are the steps followed: 1. Salinasv merged branches as above suggested by rlaager, so made the patch work against im.pidgin.pidgin branch. 2. I made the diff with the revision he merged with, then tried patching against latest snapshots. 3. Having a couple of rejects, I manually fixed them: they were simply related to the fact msn protocol now follows libpurple/MSNP9 folder, so it was an easy work. The result posted above is a patchfile working with one of the latest snapshots.

[salinasv]

Replying to msfbrasil:

Hello there!

Hi

Does anyone have any idea of when this effort will be reinitiated and mainly, when this feature will be available on main Pidgin branch and tarball file?

The work on this will be reinitiated in one or two weeks (you know, school).

The actual status is, like Twain said. I have merged the patch with i.p.p and it's working on my local mtn database. I have not uploaded a now patch because I still need to fix some bugs and stuff that I haven't been able to do because the patch was broken.

Starting this again, I guess I will finish it in 1 or 2 weeks then will upload the db somewhere so you can pull or follow the sugestions made by rlaager or some other dev.

By the way, I'm trying to get this working with the revision I have here and already noticed a problem. It seems "msn.c" and "prpl.h" are using incompatible PurplePluginProtocolInfo? structures. Best regards!!!!

[msfbrasil]

Replying to salinasv:

Hi

Hello!

The news are great!!!!.
Thank's a lot for the new path file... I'll start using it right away.

I only have some questions to make:

1- The new PurpleAccountUiOps? methods are intended to persist the custom emoticons added by the user, and the SmileyManager? (on gtksmiley.c and .h) is responsible for presenting all received smileys, right?.
For now, the impression I have is that the custom emoticons will be holded by the manager (and the application) on a per-session (or per-execution) basis, what means that the custom emoticons will need to be downloaded from the contact everytime the user restarts the application.
Am I right about that ?
If I am, is there any intention of you guys to create a definitive custom emoticon cache inside the libpurple to avoid such behavior?

2- The folder "msn" is still the right one to be used when building MSN library and folder "msnp9" is like a backup, right?

Thank's a lot!

Best regards!!!!

[rlaager]

Twain28: If you have pulled the revision from salinasv, then you shouldn't be screwing with applying patches. Given that you've already done the work, though, you want to do something like this:

1. Ask salinasv to make sure the patch is on a branch of its own. The naming doesn't really matter, but I'd recommend something like this: im.pidgin.cpw.salinasv.ticket1187. If it's not already on a branch of its own, then salinasv should run: mtn approve -b NEW_BRANCH REVISION_WITH_THE_CHANGES

2. Pull the changes from salinasv.

3. From a clean checkout of the im.pidgin.pidgin branch (i.e. upstream trunk), run: mtn merge_into_workspace h:THE_NAME_OF_THE_BRANCH_FROM_SALINASV

4. Make sure everything works. You may need to redo some of the changes that you made when developing your updated patch.

5. mtn commit -b THE_NAME_OF_THE_BRANCH_FROM_SALINASV

6. Push your changes back to salinasv.

This process will go much smoother if you'd use the version control system to your advantage instead of trying go around its back and manually work with patches.

[Twain28]

Replying to rlaager:

Twain28: If you have pulled the revision from salinasv, then you shouldn't be screwing with applying patches. Given that you've already done the work, though, you want to do something like this: 1. Ask salinasv to make sure the patch is on a branch of its own. The naming doesn't really matter, but I'd recommend something like this: im.pidgin.cpw.salinasv.ticket1187. If it's not already on a branch of its own, then salinasv should run: mtn approve -b NEW_BRANCH REVISION_WITH_THE_CHANGES 2. Pull the changes from salinasv. 3. From a clean checkout of the im.pidgin.pidgin branch (i.e. upstream trunk), run: mtn merge_into_workspace h:THE_NAME_OF_THE_BRANCH_FROM_SALINASV 4. Make sure everything works. You may need to redo some of the changes that you made when developing your updated patch. 5. mtn commit -b THE_NAME_OF_THE_BRANCH_FROM_SALINASV 6. Push your changes back to salinasv. This process will go much smoother if you'd use the version control system to your advantage instead of trying go around its back and manually work with patches.

As a matter of fact, I haven't pulled the revision from salinasv....we didn't manage to sync our dbs, so in the end he simply 7zipped his latest revision and sent it to me....that's why I posted the patch. I'm currently monitoring a defect spreaded by this patch, though, as I told you yesterday: seems some part of the patch prevents msn to store a custom avatar. I'm skimming through the code and it should be easy to spot, so I'm quite positive I'll post a solution soon....

Replying to msfbrasil:

2- The folder "msn" is still the right one to be used when building MSN library and >folder "msnp9" is like a backup, right?

No. It seems currently Pidgin got back using MSNP9, hence the new folder. The MSNP14 previously added rests in the msn folder. You'll notice compiling builds only msnp9 folder, so if you'd like to keep using msnp14, you can just rename msn folder to msnp9 and compile again. The patch I posted actually modifies both protocols, so it's just your choice. :)

[Twain28]

works with 2.2.2 with avatar!

[Twain28]

Here's a revised version of the patch: it applies correctly to Pidgin 2.2.2 source, and has avatar support.The problem was in a few lines, that removed msnp avatar storing capabilities. Will soon post also a revised patch for latest MTN snapshots.

[Twain28]

works fine with mtn im.pidgin.pidgin snapshot dated 21-11

[Twain28]

Here's the updated patch. Works fine with 91ae77ce12a4ab3798e303eea54d3bef749d5ca5 . Avatar working, obviously.

[msfbrasil]

Hello There!!!

I have some questions about the implementation of this patch that are:

1- Why methods "pidgin_account_custom_smiley_add" and "pidgin_account_custom_smiley_del" are not implemented inside the libpurple (on account API) as "purple_*" ?

2- I think the peace of code bellow, present on "pidgin_account_add_to_smiley_list" method of "gtkaccount.c" file should be inside libpurple too. Don't you agree ?

+	if(pc && prpl_info && prpl_info->add_smiley)
+		prpl_info->add_smiley(pc, smile, file, FALSE);

Best regards!!!

[msfbrasil]

Hello again!!!

Our customer has approved efforts to make the custom emoticon sending a definitive implementation inside libpurple, so I'm free to get some work from you guys to do here regarding this feature.

They want this functionality working on their application and aggreed that whether we join effort to get a final (or almost final) version running now it will avoid much of merging work on future.

My idea is to start by the suggestion's I posted yesterday about migration of code that should be inside libpurple. Another thing could be the coding of file name, because we already tried to use the custom emoticon shortcut as the file name here and faced problems because some characters that can compound the shortcut are not acceptable by the Windows file system.

Please let me know whether I can help you to get this done.

Best regards!!!

[msfbrasil]

Let me only correct myself so I don't get misunderstood.

On prior post I intended to say: ".. about migration of code that I THINK should be inside libpurple". I don't know whether you guys agree with that...

Sorry!

[salinasv]

Replying to msfbrasil:

Hello again!!! Our customer has approved efforts to make the custom emoticon sending a definitive implementation inside libpurple, so I'm free to get some work from you guys to do here regarding this feature. They want this functionality working on their application and aggreed that whether we join effort to get a final (or almost final) version running now it will avoid much of merging work on future.

Very good news!

There is no much work to do to get it working, the patch only need a little clean up and a little work on the smiley manager's tree model (you know, make it cool, think actually it sucks =( )

There is some mails on devel mailing list talking about a structure to custom emoticons IIRC Mauro is the one talking about that, maybe could be a good idea to combine efforts and get our work together.

I will be working on this full time begining tomorrow (I have just finished my last exam). As I told to twain you can find me in #pidgin.

[msfbrasil]

Hi!!!

One thing I forgot to mention yesterday is that I'll probably can help you only with libpurple side of the application, because I don't know anything of GTK.
That's why I suggested to start working with the peaces of code that could be migrated from interface (Pidgin) boundaries to libpurple.

If you still have things to do on this part of application, or if you agree with this migration of code, I'll wait a return from you here.

Anyway, it will probably sound strange, but by "find you in #pidgin" you mean...
This is a chat IRC, right ?
I never got into a chat room in my life... :-(
Can you please give me more info so I can contact you ? (like server address, etc)

Thank's and best regards!!!

[rlaager]

Replying to msfbrasil:

Can you please give me more info so I can contact you ? (like server address, etc)

Create an IRC account for irc.freenode.net. From there, you can join the #pidgin chat room from Buddies -> Join a Chat.

[msfbrasil]

Hi! I'm already waiting... nick: "msfbrasil" or "msfbrasil_123".

[echelon89]

why do this feature had not been implemented in pidgin yet? It worked well before 2.3.0.0 relase...

[msfbrasil]

Is there any reason to this feature - adding of a custom emoticon - be handled on a per-account basis? Why the custom emoticon isn't associated with a protocol, so the user can use it on every MSN account he/she have ?

[malu]

Replying to msfbrasil:

Is there any reason to this feature - adding of a custom emoticon - be handled on a per-account basis? Why the custom emoticon isn't associated with a protocol, so the user can use it on every MSN account he/she have ?

How protocol-dependent is the implementation at this moment? Would it be possible to for example add custom smileys to XMPP using an extension or emulating them on other protocols that permits inline images in messages?

[salinasv]

msfbrasil:
This patch adds API and breaks ABI and do all that we_can't_merge_it_until_3.0.0 so it will not be merged until 3.0.0 if it's complete, clean, and acepted at that time.

malu:
The development was done with prpl-independent in mind so it should not be to hard to use the same API on libpurple/pidgin to get a this feature working with other prpl

[malu]

Replying to msfbrasil:

Is there any reason to this feature - adding of a custom emoticon - be handled on a per-account basis? Why the custom emoticon isn't associated with a protocol, so the user can use it on every MSN account he/she have ?

This was my first thought to. But on the other hand, people who have several accounts on the same service may have so to separate f.ex. work and family, and maybe in this case it makes sense to keep it per account. On the other hand, if other protocols implement custom emoticons (or "emulation" of them), it might make more sense to keep a global list of emoticons (extending the standars ones per protocol).

[matthieu]

Hi guys,

how can I patch pidgin? I tried to find answers with Google but i didn't find anything helpful. I changed to Linux some time ago and I love it but I have two particularly problems 1# I couldn't use my webcam with skype (skype released a beta a couple of days ago and it works great now!) and 2# I can't send custom emoticons to msn user. I get custom emoticons but I can't send them (the msn user doesn't see them).

Would be really great if anybody could explain to me how i can patch pidgin or give me a useful link. THANKS!

[salinasv]

You should NOT use MTN(pidgin current) or any patch if you are not knowing what are you doing and ready to find AND report or fix the issues on mtn or patches.

The actual MSNP14 code is still a little crashy and the patch have some bugs.

I'm working in this with msfbrasil we are rewriting a big part of the patch generating a Smiley API and all "how it works". This should be finished soon.

Please, do not use the patch if you can't find/fix bugs.

[matthieu]

Thanks for ya precise answer! I'm looking forward to it - the day will come that i can send custom emoticons too:D

You guys do really a great job! TWO THUMBS UP - thanks to all!

[galt]

Good job, this patch works very well for me :)
Really hope to see it in 3.0.0.

[Twain28]

Any news about this? I hope holidays didn't slow your work, salinasv....in any case, this patch keeps working fine, with a little cutting/rearranging of its contents. I really wonder if it's not the time to open its own branch, as rlaager suggested.

[salinasv]

Changes needed in pidgin + Smiley Manager.

[salinasv]

Good news. I have attached 3 patches to be reviewed. they are finished.

Mauro and I have rewrite most of the code, tested it and it's working cool. This one is a lot cleaner, it adds API and breaks it in one function. So I guess we will not see it merged until 3.0.0 at least the pidgin side.

files:
msn.patch have the changes to the msn prpl. I guess this one is to khc.
smileyAPI.patch have the new api and the needed changes.
pidgin.patch is the one with most changes, have the smiley manager and the changes needed in the imhtml stuff and themes.

[khc]

I don't really like how msn_msg_emoticon_add return the augmented string and frees the param. If you need to keep appending to a string then use a GString. I think it's cleaner to change msn_send_emoticon to msn_send_emoticons and have it build up the GString internally and send it. Everything else looks fine.

[rlaager]

It sounds like khc has this under control.

[Twain28]

I'm getting stuck compiling it under Cygwin. The actual error message is:

In file included from buddyicon.h:34,
                 from blist.h:78,
                 from status.h:117,
                 from connection.h:146,
                 from account.h:42,
                 from util.h:34,
                 from smiley.h:32,
                 from smiley.c:25:
prpl.h:452: error: syntax error before "G_GNUC_NULL_TERMINATED"
prpl.h:452: warning: type defaults to `int' in declaration of `G_GNUC_NULL_TERMINATED'
prpl.h:452: warning: data definition has no type or storage class
prpl.h:492: error: syntax error before "G_GNUC_NULL_TERMINATED"
prpl.h:492: warning: type defaults to `int' in declaration of `G_GNUC_NULL_TERMINATED'
prpl.h:492: warning: data definition has no type or storage class
In file included from connection.h:146,
                 from account.h:42,
                 from util.h:34,
                 from smiley.h:32,
                 from smiley.c:25:
status.h:246: error: syntax error before "G_GNUC_NULL_TERMINATED"
status.h:246: warning: type defaults to `int' in declaration of `G_GNUC_NULL_TERMINATED'
status.h:246: warning: data definition has no type or storage class
status.h:289: error: syntax error before "G_GNUC_NULL_TERMINATED"
status.h:289: warning: type defaults to `int' in declaration of `G_GNUC_NULL_TERMINATED'
status.h:289: warning: data definition has no type or storage class
In file included from util.h:34,
                 from smiley.h:32,
                 from smiley.c:25:
account.h:426: error: syntax error before "G_GNUC_NULL_TERMINATED"
account.h:426: warning: type defaults to `int' in declaration of `G_GNUC_NULL_TERMINATED'
account.h:426: warning: data definition has no type or storage class
smiley.c: In function `parse_smiley':
smiley.c:223: warning: assignment discards qualifiers from pointer target type
smiley.c:224: warning: assignment discards qualifiers from pointer target type
smiley.c:225: warning: assignment discards qualifiers from pointer target type
make[1]: *** [smiley.o] Error 1
make[1]: Leaving directory `/home/Twain_28/newp/libpurple'
make: *** [all] Error 2

My first thought was about something missing in the Makefile.Mingw, but I've checked it and IMHO it seems allright. As you can see, I'm posting the whole warnings I get compiling smiley.o, but I'm thinking they might not be responsible for the error itself, as Salinasv told me he gets them but can compile allright in *nix. Any confirmation/fix? (In the meantime, I'm asking around about this....let's see who solves it first)

[nosnilmot]

Replying to Twain28:

I'm getting stuck compiling it under Cygwin. The actual error message is:

Add #include "internal.h" to smiley.c

[Twain28]

Replying to nosnilmot:

Replying to Twain28:

I'm getting stuck compiling it under Cygwin. The actual error message is:

Add #include "internal.h" to smiley.c

Uhm....it's already there....

[nosnilmot]

Replying to Twain28:

Replying to nosnilmot:

Replying to Twain28:

I'm getting stuck compiling it under Cygwin. The actual error message is:

Add #include "internal.h" to smiley.c

Uhm....it's already there....

So it is. Move it to before the #include "smiley.h" then :)

[Twain28]

Replying to Twain28:

Replying to nosnilmot:

Replying to Twain28:

I'm getting stuck compiling it under Cygwin. The actual error message is:

Add #include "internal.h" to smiley.c

Uhm....it's already there....

Yet adding it to smiley.h solved it!! Thank you!!!!

[salinasv]

Changed as khc told

[salinasv]

changed to compile on windows

[Twain28]

Also, please all take note the line in the pref.xml file should now be:

<pref name='custom' type='string' value='custom_smileys'/>

(It's working flawlessly, btw!)

[salinasv]

That line is not needed anymore. With the rewrite we changed to a static (no pref) dir name.

Take a look on smiley.c

[echelon89]

but, as you can see in the screenshot, it isn't still possible to receive custom emoticons
is it a problem of mine?
http://www.imagehosting.com/show.php/1517971_Schermata.jpg.html

[salinasv]

Replying to echelon89:

but, as you can see in the screenshot, it isn't still possible to receive custom emoticons
is it a problem of mine?
http://www.imagehosting.com/show.php/1517971_Schermata.jpg.html

Well In your screenshot it looks like **asd and "80" are custom emoticons and received well in pidgin. The weird things in the nickname looks like encoding problems.

BTW this patch is about *sending* emoticons.

[ebiederm]

I just played with this and got these patches to work against 2.3.1 and msnp9 I just fixed the obvious patch rejects so nothing big going on there. 2.3.1 crashed horribly when I compiled out msnp9 so I could use msnp14 so I skipped that.

In then generic custom emoticon support you probably don't want to allow the user to past in custom emoticons when the protocol does not support it. It was very confusing when I was using msnp9 and pasting things and I didn't have a clue why it wasn't working. Having them greyed out or otherwise disabled is probably desireable.

When I add a new smiley I can see it in the smiley dialog but can not use it in any conversations that predate when the smiley was added. I did not test extensively so it may just be the data entry text box with that limitation.

On a related note I can not seem to capture and save smileys when they are sent to me in conversation. Making custom smileys a little harder to use.

Does it may any sense for the generic support to convert this into an inline image transfer for the protocols that support that and not custom smileys.

Anyway it looks good and I look forward to seeing the support merged in the next version of pidgin. Thanks for all of your hard work.

Eric

[echelon89]

Replying to salinasv:

Replying to echelon89:

but, as you can see in the screenshot, it isn't still possible to receive custom emoticons
is it a problem of mine?
http://www.imagehosting.com/show.php/1517971_Schermata.jpg.html

Well In your screenshot it looks like **asd and "80" are custom emoticons and received well in pidgin.

I tried to send those emoticons from pidgin, and the other contact (in aMsn, but this also appens with other clients) didn't receive them...

The weird things in the nickname looks like encoding problems. BTW this patch is about *sending* emoticons.

I know that problem... when I use linux, some characters are not shown very well, but it isn't a problem IMHO...

[Twain28]

Replying to ebiederm:

On a related note I can not seem to capture and save smileys when they are sent to me in conversation. Making custom smileys a little harder to use.

see ticket:1421 for more about problems concerning saving custom smileys sent to you. Seems like something's missing in GTK+ itself....hence the won'tfix state of that ticket....

[malu]

Replying to Twain28:

Replying to ebiederm:

On a related note I can not seem to capture and save smileys when they are sent to me in conversation. Making custom smileys a little harder to use.

see ticket:1421 for more about problems concerning saving custom smileys sent to you. Seems like something's missing in GTK+ itself....hence the won'tfix state of that ticket....

But apperently it _is_ possible to save buddy icons that are animated gifs. I tried on a buddy who has such an icon and it saves as a gif and the animation is even preserved. So there is something that differs in the handling of "save as" for buddy icons and smileys, it seems.

[Twain28]

Replying to malu:

But apperently it _is_ possible to save buddy icons that are animated gifs. I tried on a buddy who has such an icon and it saves as a gif and the animation is even preserved. So there is something that differs in the handling of "save as" for buddy icons and smileys, it seems.

Hey, that's a good thing you spotted! Hope someone dealing with it see your tip....

[sadrul]

Since it looks like custom smileys are something we are going to support, at some stage, I am going to commit the patches to some branch to make it easier for the patch writers to update the patch in im.pidgin.pidgin.custom_smileys. If anyone objects, speak up.

Note about the current patch (mostly to myself, but someone else can tackle the issues):

• smileyAPI.patch: _image_checksum leaks in _image_filename
• smiley.c and gtksmiley.c need to be added in po/POTFILES.in
• smileyAPI.patch: fullpath leaks in _load_file
• need to hide the internals of PurpleSmiley?
• msn.c: 'emoticons' (the return value of _emoticon_add) leaks
• what's the purpose of the 'profile' tag?
• change 'varName's to 'var_name' or 'varname' (only for consistency)
• smileyAPI.patch: _load_file and _set_data_impl should be static.
• pidgin.patch: pidgin_themes_smiley_themeize can't change the signature. perhaps a new function needs to deprecate the existing one.
• Apply the change to exclude the copyright messages from the doxygen foo.
• smileyAPI.patch: why is the change in util.c:purple_markup_unescape_entity required?
• smileyAPI.patch: _new_from_data is probably a better name for _new_from_stream.
• pidgin.patch: in _del_from_list, it probably should be

                  list = g_slist_delete_link(gtk_smileys, list); 
  

• pidgin.patch: rename gaim to Pidgin in gtksmiley.h

The changes required for most of these are pretty trivial, and shouldn't really get in the way of committing the patch in the branch. But they definitely need to be addressed before it can be merged to im.pidgin.pidgin.

[sadrul]

I have applied smileyAPI.patch and pidgin.patch patches: http://developer.pidgin.im/viewmtn/revision/info/af58ab071808e2633ff0c7ca5c9b45c4c90b3974

The new branch is im.pidgin.pidgin.custom_smiley: http://developer.pidgin.im/viewmtn/branch/changes/im.pidgin.pidgin.custom_smiley

As I mentioned in the commit message, the changes in msn is still uncommitted.

Please make farther patches against the new branch.

[salinasv]

Big change in smiley.c

[salinasv]

Added a patch from Mauro and updated by me to apply on .custom_smiley.

[sadrul]

What does the change do?

[sadrul@…]

(In [473e3b581b6e7ce962e14200e16a01b15734e2be]) Modified patch ('big_smiley_change.patch') from Mauro and Jorge (Masca) to get rid of one of the hash-tables. References #1187.

[msfbrasil]

Hi!

The change on "Smiley API" eliminates a hash table, simplifies the logic and fix a problem on adding two custom emoticons that references the same image.

Best regards, Mauro.

[sadrul]

I changed the patch a little bit. Could you please make sure that the change didn't break anything?

Also, right now, as far as I can see, there can be multiple PurpleSmiley?'s with the same checksum, but only one is returned from _find_by_checksum. If we need to, we can change it to return a list of PurpleSmiley?'s with the same checksum instead. How does that sound?

[msfbrasil]

Yeah... you are quite right about that...

I haven't noticed that because I don't use this method and, if I'm not wrong about that , it's not used on Pidgin too. And your idea for the implementation seem's to be ok to me... The only thing I don't know is whether we should wait a answer from Jorge ("Masca" or "salinasv") before to make this change.

Please let me know whether you need any help or have any questions.

Best regards, Mauro.

[ventochesussurra]

If I would compile it in pidgin 2.4.0, what files I have to patch? Only "Big_smiley_change.patch"?

[sadrul]

I am going to assume the MSN part of the patch is functional. So I will fix the unfixed mem-leak issues, commit in a day or two and close this ticket. Any objections from anyone?

[ventochesussurra]

no objections. speak now or forever be silent

[nosnilmot]

no objections, it looks reasonable, but I should note that I have been meaning to look into backporting it to msnp9 too, maybe I'll find some time to do that either before or after you fix the leakiness :)

[salinasv]

AFAIK the msn patch apply clean over msnp9.

[sadrul]

The additional fixes I made to the msn patch:

• Free the 'msg' in msn_send_emoticons
  • do the same in msn_send_attention, which is not part of this patch
• Free ->obj in _emoticon_destroy
• Free 'smileys' in _grab_emoticons
• _unref 'img' in _grab_emoticons
• removed the following two lines from user.c:msn_user_set_buddy_icon:

  +   if(!msnobj)
  +       msn_object_destroy(msnobj);
  

What are these two lines supposed to do? As it is, it doesn't make any sense to me.

• Set the img using purple_imgstore_new_from_file (new API) in got_sessionreq because 'obj->img' isn't set from msn_object_new_from_string

I tried to test the changes made. But I may have missed something. Please let me know if the changes made break anything.

[sadrul@…]

(In [75e04b225965ca0ce88f89f2d921acb4ecd6dd58]) The patch to msn to allow sending custom smileys. Doesn't send all the custom smileys correctly at the moment. References #1187.

[salinasv]

Msnp9 patch back ported

[salinasv]

I added the patch to be applied over msnp9. It have the changes from sadrul. If someone looks something missing, let me know.

[phannent]

I can confirm that the msnp9 patch works on windows. If others want to test I have uploaded it here:

http://hannent.blogspot.com/2008/03/custom-emoticons-on-msn-revisited.html

[ventochesussurra]

Replying to phannent:

I can confirm that the msnp9 patch works on windows. If others want to test I have uploaded it here: http://hannent.blogspot.com/2008/03/custom-emoticons-on-msn-revisited.html

hi, wich patches did you use to compile it?
Thanks...

[Twain28]

@ sandrul: it seems we lost msn avatar support since your changes to imgstore (or maybe those two propagating?)....I propagated latest im.pidgin.pidgin on custom_smiley in my testing db and sending custom smileys went fine, yet I backtraced this avatar issue to changes made after http://developer.pidgin.im/viewmtn/revision/info/ddcc6eb918167735a0768b1a2976c95b5b15e213 Alas, I'm no real coder, so can you please check if it actually got broken? (I'm using MSNP14....I know it's not properly conventional and stable, but avatars used to work fine as well as smileys)

[sadrul@…]

(In [ed4d097cef855179282cf0b8a45f6e670d407c15]) Fix setting display picture/avatar in msnp14. Thanks to Twain28 for reporting the bug. References #1187.

[phannent]

I was a little hasty in my claims that the msnp9 patch was working, I had not updated the correct version.

Hopefully all is good now: http://hannent.blogspot.com/2008/03/pidgin-sending-custom-emoticons-msnp9.html

This is MSNP9 as opposed to Twain28's MSNP14. I tested it from my WinXP PC to Windows Live Messenger and the icon was received.

[rockya]

Do you get .gif s to send people? I can only send .png s succesfully using phannent's build, gif's don't load for the recipient (I do see them though). That's from XP SP2 to the latest WLM.

[Twain28]

Replying to rockya:

Do you get .gif s to send people? I can only send .png s succesfully using phannent's build, gif's don't load for the recipient (I do see them though). That's from XP SP2 to the latest WLM.

I do get....I wonder if there's something still missing inside msnp9....anyway, pulling down and compiling the very latest revision in the branch (using msnp14, as I do) works fine....

[phannent]

Gif sending working

[phannent]

Replying to rockya:

Do you get .gif s to send people? I can only send .png s succesfully using phannent's build, gif's don't load for the recipient (I do see them though). That's from XP SP2 to the latest WLM.

I tested it this morning on my MSNP9 build and all seems fine (see the attached proof). Could you attach the image you are having problems with?

[phannent]

This is a stable patch. Could I ask what needs to be completed for it to be merged with the trunk?

[rockya]

Yeah, just tested and it's working now for me too. It didn't though yesterday with any .gif. Strange...

One other thing: I seem to get a crash if I try to save a .gif. The first time I try it says it defaults to .png and the second it crashes. Don't know if thats related to this patch though.

[salinasv]

Replying to rockya:

One other thing: I seem to get a crash if I try to save a .gif. The first time I try it says it defaults to .png and the second it crashes. Don't know if thats related to this patch though.

The patch is about *sending* custom smileys. The problem when saving an incoming smiley is not related I know there is a problem with this. I guess I will try to figure what is wrong, btw it's not possible to save an animated smiley, it will be saved as png.

[datallah]

Replying to rockya:

One other thing: I seem to get a crash if I try to save a .gif. The first time I try it says it defaults to .png and the second it crashes. Don't know if thats related to this patch though.

You're probably seeing #5217.

[sadrul@…]

(In [762e0e84f778841d4021f4d8ea5c39bff5e173b2]) Update patch to add support for sending custom smileys in msnp9. I included some fixes from the msnp14 patch that were not corrected in the patch, and also the fix for setting buddyicons. References #1187.

[sadrul]

How about we merge this to i.p.p, now that 2.4.1 is released? (this will bump the minor)

[nosnilmot]

Replying to sadrul:

How about we merge this to i.p.p, now that 2.4.1 is released? (this will bump the minor)

I'm certainly in favor of this in general but before we commit im.pidgin.pidgin to becoming next.minor I'd like to give it at least a few more hours before we declare 2.4.1 "good" (I did have something to do with its release, so probably screwed something up)

Other than that, sadrul, you rock for taking care of the msnp9 bits here already!

[Dobrosslove]

(n00b_question)Please,can you tell me how to apply the patch to send custom smileys in MSN?(/n00b_question)

[Twain28]

Replying to Dobrosslove:

(n00b_question)Please,can you tell me how to apply the patch to send custom smileys in MSN?(/n00b_question)

You don't. Just check the TRAC's UsingPidginMonotone , checkout the latest build from the dedicated branch and build.

Question for the mantainers, regarding the Custom Smiley Manager: could you add the possibility to sort custom smileys in it by clicking on the "Smiley" and "Shortcut" columns? Right now the window has no sort criteria, and things are getting messy with my 330+ smileys....

[salinasv]

Replying to Dobrosslove:

(n00b_question)Please,can you tell me how to apply the patch to send custom smileys in MSN?(/n00b_question)

If you don't know how to apply a patch, you should not use mtn code. Wait until this patch is merged in and released.

[ventochesussurra]

does anybody know when this patch will be merged and relased?

[Twain28]

Figured the scrap of code needed to be able to sort by shortcut by myself: just insert

gtk_tree_view_column_set_sort_column_id(column,
                                        SHORTCUT);

under the "/* Shortcut */" section into the "Smiley Manager"part of gtksmiley.c . Easy and sound. :P

[QuLogic]

OK, so I tried out this branch, and I'd like to point out a few minor things that would make it a bit better.

First, there's no preview until after you've pressed Add. It would be nice to see a preview in the file browser (like the Buddy Icon selector), or at least in the 'Add Smiley' dialog. That wouldn't be too bad, except you can't edit a shortcut once made, either. Double-click to edit would be nice, when in the Custom Smiley Manager. Also, it doesn't check whether you've added an image or just some random file, which might cause problems with other clients (Pidgin on the receiving end didn't seem to care, for what I tried, but who knows).

Finally, while the smiley does seem to be sent, it shows up in the local window as just plaintext. However, I'm not sure whether that's broken, or it's just because I'm testing out Sean's WebKit plugin at the same time.

[Twain28]

Replying to QuLogic:

OK, so I tried out this branch, and I'd like to point out a few minor things that would make it a bit better. First, there's no preview until after you've pressed Add. It would be nice to see a preview in the file browser (like the Buddy Icon selector), or at least in the 'Add Smiley' dialog. That wouldn't be too bad, except you can't edit a shortcut once made, either. Double-click to edit would be nice, when in the Custom Smiley Manager. Also, it doesn't check whether you've added an image or just some random file, which might cause problems with other clients (Pidgin on the receiving end didn't seem to care, for what I tried, but who knows).

I totally agree. A preview in the "add Smiley" might be the lightest idea, to avoid hogging the system.

Finally, while the smiley does seem to be sent, it shows up in the local window as just plaintext. However, I'm not sure whether that's broken, or it's just because I'm testing out Sean's WebKit plugin at the same time.

Yep, that's only you....I'm using this branch since it started, and in my local window I can see perfectly well the smiley when typing its shortcut. :)

[QuLogic]

Replying to Twain28:

I totally agree. A preview in the "add Smiley" might be the lightest idea, to avoid hogging the system.

I suggested the file browser because it shouldn't be too difficult to just copy the code from buddy-icon selector, but really, it would be nice in both places.

Yep, that's only you....I'm using this branch since it started, and in my local window I can see perfectly well the smiley when typing its shortcut. :)

Ah yes, it is the WebKit plugin. It seems to have a few issues with disabling/enabling after startup.

[malu]

I just checked out this branch. When using the "smiley manager", I thought it would look better if the list view had a shadow set. So, I made a little patch. This sets SHADOW_IN on the smiley list.

[salinasv]

Add a preview in the add dialog + shadow + sort by shortcut

[sadrul]

ecbdfa4082a0e9f3e56cdbe7ebca8f3a00d6d0d9:

Patch from Masca to use the buddy-icon selector to select a custom
smiley. This gives us the preview widget for free, which is really nice.
The patch also uses the icon-selector button we use for accounts in the
smiley dialog, which is also very cool.
This commit also includes some changes I made to make it possible to edit
an existing smiley, by double clicking in the treeview. I merged this
change with the changes in Masca's patch. I am hoping I didn't break
anything in the process. If I did, let me know early before I forget
whatever the heck I did!

That takes care of QuLogic's suggestions. The committed patch also includes malu's latest patch (which I realized was there only after the commit, which is why I couldn't acknowledge in the commit message. Sorry! :( )

Any other suggestions/bugs -- UI or API or other wise?

[sadrul@…]

(In [fb801dc3cb44bc81a383a9e0a44ba099a3e99d1e]):
Fix a small leak. And sort the smileys alphabetically, as suggested by Masca and Twain28. References #1187.

[phannent]

Hello,

I have compiled this version for windows XP. Anybody interested in testing can download from my site: http://hannent.blogspot.com/2008/04/latest-pidgin-with-custom-emoticon.html

I will try this week to test it on my ubuntu box.

Both the MSNP9 and MSNP15 work fine as far as I can tell. No crashes to report so far (of 1 hour of usage).

[malu]

Replying to sadrul:

ecbdfa4082a0e9f3e56cdbe7ebca8f3a00d6d0d9: {{{ Patch from Masca to use the buddy-icon selector to select a custom smiley. This gives us the preview widget for free, which is really nice. The patch also uses the icon-selector button we use for accounts in the smiley dialog, which is also very cool. This commit also includes some changes I made to make it possible to edit an existing smiley, by double clicking in the treeview. I merged this change with the changes in Masca's patch. I am hoping I didn't break anything in the process. If I did, let me know early before I forget whatever the heck I did! }}} That takes care of QuLogic's suggestions. The committed patch also includes malu's latest patch (which I realized was there only after the commit, which is why I couldn't acknowledge in the commit message. Sorry! :( ) Any other suggestions/bugs -- UI or API or other wise?

I noticed that when adding a smiley, the image button has the same size as the buddy icon selector and after I had selected the icon, it was scaled up quite up a bit. Then when double-clicking the smiley in the mananger to edit it, the image button was the size of the icon, which looked a bit better.

Maybe the initial size of the button could be set to a "typical smiley size". I assume this is because the button is orginally loaded with the buddy icon stock image. Perhaps it could use the smiley stock image (the same as in the toolbar/tools menu)? I don't know if this requires big changes...

Also I noticed that when adding a new smiley and then using that smiley in a conversation that was started before I added it, it shows up in the smiley selector, but in the text input field the shortcut is shown. But after sending the message the smiley appears in the conversation log.

[echelon89]

Screenshot of pidgin 2.4.2-devel with msnp14

[echelon89]

I've compiled it for ubuntu. You can download it here
Have fun! :P

[ferk]

Nice one!! But.. doesn't pidgin have already a emoticon pack system?

I think that it can be confusing for the user to have different emoticons systems, and maybe the shortcuts can even conflict with the previous packs.

In my humble opinion, as a suggestion, a better approach will be to let the user edit the current packs in a friendly way and use those emoticons as custom.

It will be very nice to be able to use all those packs the community already worked for as custom emoticons.

[ferk]

On the other hand.. adding custom emoticons one by one can be an annoying task when you want to add a whole pack of emoticons.

[sadrul]

The smileys from the 'emoticon pack system'/'smiley theme' are local only, i.e., the smiley you see at your end is not sent to user B at the other end. User B can use a different set of smileys, or no smileys at all.

The custom smileys this patch/branch deals with are different. In this case, the smileys (i.e., the shortcuts and the image data) are sent to user B during a conversation, and user B will see exactly the same smiley/image as you. (of course, we allow ignoring custom smileys for good reason).

Allowing custom smileys, in addition to the 'normal' smileys, in a 'smiley theme' might be worth looking into.

[kasmol]

there are some custom emoticons that are too big, can you make a limit for their size?on wlm I think that this limit is 96x96, correct me if I'm wrong.

[Twain28]

Replying to kasmol:

there are some custom emoticons that are too big, can you make a limit for their size?on wlm I think that this limit is 96x96, correct me if I'm wrong.

The max size allowed should be 100x100x150kb, if I remember well....yet it would be pointless to put it as a limit....instead, why not implementing something similar to the autoresizing used for avatars? It could easily take care of the 100x100 limit (not sure about the 150kb one, though), and could avoid the horrible resizing operation WLM sometimes does when recieving our custom big ones....

[galt]

IIRC, WLM doesn't resize on send either, so while it might be nice to resize, not doing so is consistent with the official client's behaviour. I think either way is fine.

[jpaixao]

hi!

I'm using pidgin-2.4.2devel and I believe there is some kind of memory leak.

every time I select the Smile! button in a conversation windown, the application uses 25Mb more memory.

the first time I notice it, pidgin was using 300Mb of memory. the only solution I found to get pidgin back to normal is to restart de program.

[phannent]

I can confirm the memory usage problem on my windows build.

[sadrul]

I can see one leak in there. The following change should fix it:

============================================================
--- pidgin/gtkimhtmltoolbar.c   040b48544e6fd9aeef583eb8fab648122017903f
+++ pidgin/gtkimhtmltoolbar.c   4974500f465b6c7c24cd17a1c5b81e3927442401
@@ -771,10 +771,9 @@ insert_smiley_cb(GtkWidget *smiley, GtkI
                while (unique_smileys) {
                        GtkIMHtmlSmiley *smiley = unique_smileys->data;
                        if (!smiley->hidden) {
-                               fflush(stdout);
                                ls = sort_smileys(ls, toolbar, &max_line_width, smiley->file, smiley->smile);
                        }
-                       unique_smileys = unique_smileys->next;
+                       unique_smileys = g_slist_delete_link(unique_smileys, unique_smileys);
                }
                /* pack buttons of the list */
                max_line_width = max_line_width / num_lines;

Does the memory usage go down with that change?

[sadrul@…]

(In [230dccf2c8ea29f62c32e122ea727b9c36cc8d1d]):
Unref some gdkpixbufs to plug some memory leaks. References #1187.

[sadrul]

That last commit should get rid of some of the memory usage.

It looks like the custom smileys are displayed in accounts/protocols that don't support custom smileys (e.g. in an AIM conversation). I don't think that should happen. Perhaps we should use some ConnectionFlags? to determine whether the prpl/account supports custom smileys or not, and use them appropriately. Thoughts?

[malu]

Replying to sadrul:

That last commit should get rid of some of the memory usage. It looks like the custom smileys are displayed in accounts/protocols that don't support custom smileys (e.g. in an AIM conversation). I don't think that should happen. Perhaps we should use some ConnectionFlags? to determine whether the prpl/account supports custom smileys or not, and use them appropriately. Thoughts?

That sounds like a good idea. When using my patch on ticket #5627 for XMPP it actually only makes sense to use the custom smileys if the buddy supports XHTML-IM (since they are only included when the message is sent with an xhtml element attached). So it might make sense to have some way of determining per buddy, perhaps.

[sadrul]

I have http://pidgin.im/~sadrul/pp/custom_smiley_on_supported_accounts.patch, which seems to work OK with MSN.

malu: Do you think that's going to work on XMPP with your patch? If the overhead bandwidth is not huge (I suspect it isn't), it's probably OK to send out the stuff even if the buddy doesn't see them; I don't really know.

[QuLogic]

So I noticed a little bug, depending on how you look at it. At the moment, you can define a smiley which replaces the default ones (like :), :(, etc). This is not necessarily a bad thing, but at the moment, MSN doesn't currently allow you to re-define these shortcuts (in the GUI). I don't know about XMPP.

On the other hand, MSN allows receiving the custom smiley, but Pidgin does not (though I only tried the official release for this side).

[kasmol]

If I select a custom emoticon it appears in the text box, if I write the shortcut it don't appear in the text box, why?(only in the text box, after that I send the message, I see every custom emoticons)

[malu]

Replying to sadrul:

I have http://pidgin.im/~sadrul/pp/custom_smiley_on_supported_accounts.patch, which seems to work OK with MSN. malu: Do you think that's going to work on XMPP with your patch? If the overhead bandwidth is not huge (I suspect it isn't), it's probably OK to send out the stuff even if the buddy doesn't see them; I don't really know.

I think that will work well. Since the smiley's shortcut is set as the img's alt attribute, an XHTML-IM parser should ideally show that if it doesn't want show the image. The overhead will typically be quite small. I've been using some smileys I found in some "Smiley pack for Messenger", they are basically < 2 kB. When sending a message containing such a smiley to myself (taking a trip back and forth under the Atlantic) I can't say I can notice any difference from a text-only message. And at least in Psi and Gmail the other user still sees the shortcut.

[malu]

Replying to QuLogic:

So I noticed a little bug, depending on how you look at it. At the moment, you can define a smiley which replaces the default ones (like :), :(, etc). This is not necessarily a bad thing, but at the moment, MSN doesn't currently allow you to re-define these shortcuts (in the GUI). I don't know about XMPP. On the other hand, MSN allows receiving the custom smiley, but Pidgin does not (though I only tried the official release for this side).

The XMPP XEP uses <img/> tags in XHTML-IM to send inline images. So I have mapped the shortcut to the "alt" attribute.

Perhaps there could be a warning if a user tries to use a predefined shortcut, but I'm not quite sure how that would work with multiple protocols. It would be strange if it was warning you about a protocol you don't use. On the other hand you could add an account using shortcuts as defaults for which you have defined custom emoticons. I guess it will be up to user to use unique shortcuts. Maybe default emoticons for which you have "overridden" the shortcut could be shown "greyed out" in the smiley selection dialog...

[malu]

Replying to kasmol:

If I select a custom emoticon it appears in the text box, if I write the shortcut it don't appear in the text box, why?(only in the text box, after that I send the message, I see every custom emoticons)

This happens also for ordinary smileys and is the expected behaviour. The "gtkimhtml" editor Pidgin uses currently doesn't replace text with smileys as you type. There is ticket for this behaviour.

[sadrul]

@malu: Terrific! I have committed the patch, and your leak fix.

We currently detect multiple custom smileys for the same key/shortcut. Greying out the 'normal' smileys when there's a custom smiley for the same key sounds like a good idea. Who wants to write the patch? ;)

[malu]

Replying to sadrul:

@malu: Terrific! I have committed the patch, and your leak fix. We currently detect multiple custom smileys for the same key/shortcut. Greying out the 'normal' smileys when there's a custom smiley for the same key sounds like a good idea. Who wants to write the patch? ;)

I'm taking a look at the greying-out function right now... I'll hopefully have something working tomorrow.

[salinasv]

Yeah, the gtkimhtml is the problem with no showing the smiley in the entry. I hope this could be fix with the new Webkit.

About the smiley themes + custom smiley. I really think the guy with the Themes SoC must rewrite the themes API considering the stock and custom smileys then it can be really trivial to integrate both.

/me put his hopes on SoC projects.

[kasmol]

Replying to malu:

This happens also for ordinary smileys and is the expected behaviour. The "gtkimhtml" editor Pidgin uses currently doesn't replace text with smileys as you type. There is ticket for this behaviour.

where is this ticket?

[galt]

kasmol: #1787

[malu]

Grey out default smileys when there is a custom smiley with the same shortcut

[malu]

Added a patch that greys out default smileys if there is a custom smiley with the same shortcut (and the current connection uses custom smileys)

[durand]

Replying to echelon89:

I've compiled it for ubuntu. You can download it here
Have fun! :P

Thanks for that build!!!

I wrote a python script to export any smiley theme file to a smileys.xml file: http://durand.zephyrhosting.net/dump/python/smileys.tar.bz2 I wrote the script just to learn python so its a bit messy. I've included an example smileys.xml file with most of the default pidgin smileys config. You need to edit infile and outfile in pidgin_smileys.py to your smileys theme file (eg. /usr/share/pixmaps/pidgin/emotes/default/theme) and your output to the output file.

Since the script is still premature, you HAVE to change the theme file to only include the smiley lines. EG, no headers or title lines (like [MSN])

Then run pidgin_smileys.py. You can then use recurrences.py to check if a smiley has been repeated and you can then manually edit the smileys.xml file. Finally, exit pidgin, copy the smileys.xml file over to ~/.purple and symlink (or copy) the directory with the smileys in it to ~/.purple/custom_smileys.

[durand]

Oops, forgot to mention that you need to remove any characters like <,> and ' from the shortcuts value in the smileys.xml file.

[sadrul@…]

(In [7068f7a4e3f16e64b6fee5a80081a052c4be8730]):
Patch from malu (mlundblad) to disable a regular smiley in the smiley dialog if there's a custom smiley for the same shortcut. References #1187.

[phannent]

I can report that the memory leak has been fixed. I have just built new version for windows.

http://hannent.blogspot.com/2008/05/race-with-twin28.html

I tried to propagate from the trunk but there was a merge conflict. Which I do not have time to look at.

[echelon89]

I've updated mine too pidgin debs
now with plus plugin!

[malu]

Adds an "edit" button to the smiley manager

[malu]

I added an "edit" button to the smiley manager in the last patch...

[sadrul@…]

(In [c134ff23eba5faac09c13e731e792fa612c91a9a]):
Modified patch from malu to add an 'Edit' button in the smiley manager dialog. References #1187.

[sadrul]

I have propagated this branch to im.pidgin.pidgin.next.minor. If there are more patches about custom smileys, please make them against .next.minor, and create new tickets, because I am closing this one!

[salinasv]

Great! One 'yeeii' for this ticket being closed.

This is the biggest no-user-complaining ticket I have seen here.

[malu]

Replying to sadrul:

I have propagated this branch to im.pidgin.pidgin.next.minor. If there are more patches about custom smileys, please make them against .next.minor, and create new tickets, because I am closing this one!

Cool! I have been following this ticket more or less since the beginning (I think it's almost exactly one year...). It is almost a bit surrealistic it is now getting closed :-)

[phannent]

Wow, very cool. Thanks for merging this.

Not sure what I will do now? Find some other ticket to hang out on I guess.

I built the next.minor branch for those that want to test: http://hannent.blogspot.com/2008/05/merged-at-last.html

[echelon89]

Replying to malu:

Replying to sadrul:

I have propagated this branch to im.pidgin.pidgin.next.minor. If there are more patches about custom smileys, please make them against .next.minor, and create new tickets, because I am closing this one!

Cool! I have been following this ticket more or less since the beginning (I think it's almost exactly one year...). It is almost a bit surrealistic it is now getting closed :-)

lol it's the same for me! :P

[echelon89]

I've updated my debs for ubuntu too
branch is im.pidgin.pidgin.next.minor
download here

sorry for double posting

[phannent]

I know this ticket is closed but some might be interested to have the latest build for windows plus the XMPP emoticons:

http://hannent.blogspot.com/2008/05/jabber-custom-emoticons.html

[echelon89]

mine are upgraded too!

download here

[ferk]

thank you so much! ... I believe that version 2.5.0 will be a pretty good jump for pidgin if all of this is on it.

echelon89... does your build also have the XMPP emoticons? I installed it but the emoticons don't show in XMPP, I'm not sure if this is a bug for the patch or it is not included in your build.

[echelon89]

Replying to ferk:

thank you so much! ... I believe that version 2.5.0 will be a pretty good jump for pidgin if all of this is on it. echelon89... does your build also have the XMPP emoticons? I installed it but the emoticons don't show in XMPP, I'm not sure if this is a bug for the patch or it is not included in your build.

no, XMPP emoticons patch is not included, yet

[paddy2706]

Is there a way to enable caching the custom emoticons that others send me to .purple/icons or .purple/smileys?

I re-cycle many emoticons for the collection of emoticons that I have received are quite big so if I needed one I used to copy it from the .amsn cache so far and I'd love to get that behaviour with pidgin aswell.

[phannent]

Replying to paddy2706:

Is there a way to enable caching the custom emoticons that others send me to .purple/icons or .purple/smileys? I re-cycle many emoticons for the collection of emoticons that I have received are quite big so if I needed one I used to copy it from the .amsn cache so far and I'd love to get that behaviour with pidgin aswell.

When someone sends you an icon you can right click on it to add it to your collection, if you have files on a disk you can add them with the Python script someone created in comment 151.

[durand]

I made the script in #151 but it's only for pidgin smiley themes, ie, images with a theme file. This is because the script links the images to a shortcut.

[salinasv]

If you want to import a whole set of images I guees it can be easy to create a plugin to do it.

[paddy2706]

Replying to salinasv:

If you want to import a whole set of images I guees it can be easy to create a plugin to do it.

the thing is actually not importing them but having them stored automatically on the harddisk (emesene and amsn do that) - it also makes loading previously used images faster

[mikerobinson]

Without having to read through all of these posts, what do I have to do to get custom smileys working for MSN? It is listed as "Closed", so I am assuming that a solution exists. I am having these three problems:

- When I right click on a custom smiley that someone sends and choose "Add custom smiley", I am able to type in the text I want for it and I can see the image there, but it doesn't work when I try to save it. - Probably related to this, when I right click on a custom smiley someone sends and choose to save it, it gives me an error message saying something about it being an invalid image format and it is defaulting to png, but doesn't save it as anything. - When I add an image to my custom smileys from my local computer, it works and when I send the message, the smiley appears to me, but not the other person.

Thanks.

[salinasv]

Replying to mikerobinson:

Without having to read through all of these posts, what do I have to do to get custom smileys working for MSN? It is listed as "Closed", so I am assuming that a solution exists. I am having these three problems: - When I right click on a custom smiley that someone sends and choose "Add custom smiley", I am able to type in the text I want for it and I can see the image there, but it doesn't work when I try to save it. - Probably related to this, when I right click on a custom smiley someone sends and choose to save it, it gives me an error message saying something about it being an invalid image format and it is defaulting to png, but doesn't save it as anything. - When I add an image to my custom smileys from my local computer, it works and when I send the message, the smiley appears to me, but not the other person. Thanks.

Please open a new ticket and attach the debug output you get when adding the smiley.