Menu
▾
▴
pidgin-patches — Updates to the Gaim patches tracker
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(435) |
Dec
(252) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(177) |
Feb
(157) |
Mar
(187) |
Apr
(168) |
May
(127) |
Jun
(291) |
Jul
(38) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-03-18 16:38:57
|
Patches item #1166073, was opened at 2005-03-18 16:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Kahn (xkahn) Assigned to: Nobody/Anonymous (nobody) Summary: Make the autocorrect plugin work Initial Comment: Autocorrect in gaim... um... sucks. The problem is that the correction only happens AFTER you send a message. This means that you don't actually know what message you are sending until it is sent. Horrible. My new patch works AS YOU TYPE with the following rules: * You must be typing, not pasting in text. If you paste in teh and there is a rule to correct teh to the, it won't be corrected. This is because it would be impossible to go back and check all the text. * Check whole words ONLY. Partial words don't count. * If the dictionary word has capital letters in it, match only words with that capitalization. (FPT -> FTP doesn't match ftp.) * If the dictionary word doesn't have capital letters, preserve the capitalization the user used. (The code assumes three possible capitalization schemes: ALLCAPS, lowercase, and Proper.) Unless the solution has capital letters. In that case, force the capitalization used in the solution. * A word may have quote characters in it and still be a word. * If the user immediately hits the backspace key after a correction, undo the correction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-17 03:25:52
|
Patches item #1121104, was opened at 2005-02-12 09:41 Message generated for change (Comment added) made by bleeter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1121104&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bleeter Yaluser (bleeter) Assigned to: Tim Ringenbach (marv_sf) Summary: Yahoo privacy fixes Initial Comment: The yahoo prpl has no real concept of privacy, beyond what Yahoo servers offer. Here's a patch that addresses most of these issues. 1) Introduce a privacy check routine. Ideally, this should be in privacy.c, but it's esier to submit in here for the moment, for simple testing. If people think it's worthy to be added before complete privacy rewrite, it can be moved. 2) Each incoming message can be checked against this function. Thus, all typing, IMs and chat invites can be blocked. 3) The permit/deny list is now active. As yahoo protocol has no concept beyond blocking, this acts locally only. I've submitted to head, as although I believe this is actually a bugfix, it's best to submit here and backport (although it was written against oldstatus and forward poted originally) ---------------------------------------------------------------------- >Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-17 14:25 Message: Logged In: YES user_id=407708 It would appear there's something deeply wrong with privacy, where 0 = 1. Go figure. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-09 13:12 Message: Logged In: YES user_id=407708 Ok, here's an initial 1.x patch. Comments welcome. I've done *some* tidying up. More comments welcome. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-09 11:02 Message: Logged In: YES user_id=407708 There's one more 'thing' I'd like to get in here, for ease of chat UI use. Give me a few hours. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-08 12:36 Message: Logged In: YES user_id=407708 Yes, I realised I'd not blocked chat invites after I posted this. I've added it to my later versions ;-) I did originally have buckets of debug in the code, but ripped most of it out for publishing. I'll put what you sugegst back in. Whitespace fix won't be a problem :-) I'd tried keeping formatting consistency with other gaim code, but as ou know, that's not always a useful guide ;-) Should have an update for you in 24 hours or so. Do you want a 1.x backport as well? Actually, it originates as a 1.x patch, and I forwardport. ---------------------------------------------------------------------- Comment By: Tim Ringenbach (marv_sf) Date: 2005-03-08 11:50 Message: Logged In: YES user_id=790708 Actually, you just block conference invites, not chat invites. You might want to block both. I don't suppose you could work in some kind of gaim_debug warning if we receive an IM from someone on the block list when we're in "block the users below"? Because we shouldn't be getting IM's from users like that, and covering up the bug will just make it harder to fix. (the bug being the people aren't ending up on the server side block list) Also, could you fix the whitespace? Like, the switch statement isn't indented at all. Nothing should be not indented at all except function names and the opening { for the function.. I do usually have the switch and the cases below it at the same indentation level, e.g.: switch () { case: default: } I don't know how right that is, or if gaim has a genereal rule for it though. Also, I usually put no space between a function and the (), like "printf("hello!");", but I always put a space if it's a flow control thingy, like "if (foo != bar) {" For multiline functions, something like <tab>printf("%s%s%s", <tab><space><space><space><space>blah, blah, blah); Is probably better, than multiple tabs. The important thing is the same number of tabs is used on both lines, so the line looks right whether the tab is 4 or 8 spaces. Also, you should probably use gaim_debug_info() instead of gaim_debug(GAIM_DEBUG_INFO) I think that's all the nit picking for now. If you fix at least some of what i complained about i'll apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1121104&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-16 03:02:41
|
Patches item #1108529, was opened at 2005-01-24 13:24 Message generated for change (Comment added) made by belyi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1108529&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Igor Belyi (belyi) Assigned to: Sean Egan (seanegan) Summary: Keep formating when a message is sent. Initial Comment: This is similar to "[ 1093125 ] Maintain formatting between messages within a conversation" but without any extra Preferences. I consider it a bug fixing patch. Please, feel free to disagree. :o) Markup buttons (bold, italic, underline, font) are triggered back into some predefined state even when "Default Formatting" is not checked in the "Message Text" of the Preferences. The attached patch fixes this problem. With this patch markup state get reset to the predefined in this preference format only when "Default Formatting" is checked. I hope you like it. Igor ---------------------------------------------------------------------- >Comment By: Igor Belyi (belyi) Date: 2005-03-15 22:02 Message: Logged In: YES user_id=995711 I apologize for not replying for so long. No, this patch does not address the problem of the text being green all the time - it solves completely different problem of the text always returning to some predefined state even if you don't want to. Do you still want me to redo the patch against CVS? Regarding text being green - do you know that different chat protocols support different text markups? IM, for example supports formating only of the whole text. Therefore, if you change formating of the text to green - the whole buffer should become green since this is how your text will be seen to your reader. Other protocols do not allow markups at all and therefore if you have account in them and still able to change formating - this can be considered a bug since for those protocols all formating buttons should be disabled. Cheers, Igor ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-03-07 13:58 Message: Logged In: YES user_id=199625 I'm going to commit this and see if I can't make sure the bug is fixed myself. Thanks, Igor. :) ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-02-27 17:27 Message: Logged In: YES user_id=199625 Just for clarification: The current problem with me accepting this feature is there's currently no good way to remove formatting once it's already there. For instance, I've pasted green text into the GtkIMHtml before and then whatever I type after that is still green. If this patch doesn't address that, everything I type after pasting green text will be green, despite that I only wanted the few words I pasted to be green. Is that fixed by this patch? Also, could you make a patch against CVS HEAD? -s. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1108529&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 22:41:15
|
Patches item #1163319, was opened at 2005-03-14 16:27 Message generated for change (Comment added) made by rizzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1163319&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Don Seiler (rizzo) Assigned to: Sean Egan (seanegan) Summary: UI for gaim account option lists Initial Comment: gaim account option lists currently have no UI. I've implemented one here. I've also changed the account option list API to take a GList of GaimKeyValuePair structs (also included in this patch) rather than a GList of key-then-value-then-key-then-value-etc. strings. Patch includes the implementation of the UI in add_protocol_options(), and the call back function in ok_account_prefs_cb(). The destroyer that had already been implemented should still apply in this case given static strings. This makes use of the GtkComboBox, which I'm told will be available in HEAD, and this was diffed from HEAD. Here is an example use from the PRPL init_plugin(): GaimKeyValuePair *kvp; GList *server_list = NULL; kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("Asia"); kvp->value = "asia.battle.net"; server_list = g_list_append (server_list, kvp); kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("Europe"); kvp->value = "europe.battle.net"; server_list = g_list_append (server_list, kvp); kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("US - East"); kvp->value = "useast.battle.net"; server_list = g_list_append (server_list, kvp); option = gaim_account_option_list_new(_("Server List"), "server_list", server_list); prpl_info.protocol_options = g_list_append(prpl_info.protocol_options, option); ---------------------------------------------------------------------- >Comment By: Don Seiler (rizzo) Date: 2005-03-14 16:41 Message: Logged In: YES user_id=61900 Just a follow-up note that this is really part one of a two-part change. Part two involves using an array instead of a GList to pass the kvps, and then making the PRPL responsible for destruction of that array and any other option-related variables, which would be done in the plugin unload() function. See the recent email thread started by me and added-to by Ethan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1163319&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 22:31:38
|
Patches item #1163319, was opened at 2005-03-14 17:27 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1163319&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Don Seiler (rizzo) >Assigned to: Sean Egan (seanegan) Summary: UI for gaim account option lists Initial Comment: gaim account option lists currently have no UI. I've implemented one here. I've also changed the account option list API to take a GList of GaimKeyValuePair structs (also included in this patch) rather than a GList of key-then-value-then-key-then-value-etc. strings. Patch includes the implementation of the UI in add_protocol_options(), and the call back function in ok_account_prefs_cb(). The destroyer that had already been implemented should still apply in this case given static strings. This makes use of the GtkComboBox, which I'm told will be available in HEAD, and this was diffed from HEAD. Here is an example use from the PRPL init_plugin(): GaimKeyValuePair *kvp; GList *server_list = NULL; kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("Asia"); kvp->value = "asia.battle.net"; server_list = g_list_append (server_list, kvp); kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("Europe"); kvp->value = "europe.battle.net"; server_list = g_list_append (server_list, kvp); kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("US - East"); kvp->value = "useast.battle.net"; server_list = g_list_append (server_list, kvp); option = gaim_account_option_list_new(_("Server List"), "server_list", server_list); prpl_info.protocol_options = g_list_append(prpl_info.protocol_options, option); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1163319&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 22:27:29
|
Patches item #1163319, was opened at 2005-03-14 16:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1163319&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Don Seiler (rizzo) Assigned to: Nobody/Anonymous (nobody) Summary: UI for gaim account option lists Initial Comment: gaim account option lists currently have no UI. I've implemented one here. I've also changed the account option list API to take a GList of GaimKeyValuePair structs (also included in this patch) rather than a GList of key-then-value-then-key-then-value-etc. strings. Patch includes the implementation of the UI in add_protocol_options(), and the call back function in ok_account_prefs_cb(). The destroyer that had already been implemented should still apply in this case given static strings. This makes use of the GtkComboBox, which I'm told will be available in HEAD, and this was diffed from HEAD. Here is an example use from the PRPL init_plugin(): GaimKeyValuePair *kvp; GList *server_list = NULL; kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("Asia"); kvp->value = "asia.battle.net"; server_list = g_list_append (server_list, kvp); kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("Europe"); kvp->value = "europe.battle.net"; server_list = g_list_append (server_list, kvp); kvp = g_new(GaimKeyValuePair, 1); kvp->key = _("US - East"); kvp->value = "useast.battle.net"; server_list = g_list_append (server_list, kvp); option = gaim_account_option_list_new(_("Server List"), "server_list", server_list); prpl_info.protocol_options = g_list_append(prpl_info.protocol_options, option); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1163319&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 12:50:36
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: rian hunter (chrono86) >Assigned to: Ethan Blanton (eblanton) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 08:27:53
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Nobody/Anonymous (nobody) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 04:08:47
|
Patches item #982227, was opened at 2004-06-29 15:13 Message generated for change (Comment added) made by charkins You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=982227&group_id=235 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Casey Harkins (charkins) Assigned to: Sean Egan (seanegan) Summary: docklet: play message received sound when message is waiting Initial Comment: This patch to the system tray plugin adds a preference option to play the message received sound when a message is waiting. The sound is played when the status changes to online_pending. ---------------------------------------------------------------------- >Comment By: Casey Harkins (charkins) Date: 2005-03-13 22:08 Message: Logged In: YES user_id=254876 You have the behavior correct, I imagine there was some reason I did that rather than playing a sound for each message. :-) I will try to find time soon to finish refactoring the sound code to respond to signals. Thanks for the tip on looking at pounces. I'll resubmit when i get it workin. ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-03-13 17:13 Message: Logged In: YES user_id=199625 Unless I'm mistaken, this patch will only play a sound the first time a message is received while messages are queued. That's no good. I agree that using the signals mechanism is a good solution. Look at how pounces work for pointers. -s. ---------------------------------------------------------------------- Comment By: Casey Harkins (charkins) Date: 2005-03-08 10:40 Message: Logged In: YES user_id=254876 For the record, I think the correct approach to fixing this and potentially other sound issues is to move all existing gaim sound code into a plugin. Sound events already occur is situations where a signal is being emitted. Using a plugin would allow the sounds to be de-coupled from the interface (the problem in this particular case). It should also simplify the codebase as sound support would be entirely self contained within a plugin instead of littered throughout the core components. I had started work on this a few months ago, but haven't found time to finish it up. I was planning on working on this again soon, unless someone beats me to it. Anyone agree or disagree with moving all sound support into a plugin? ---------------------------------------------------------------------- Comment By: Casey Harkins (charkins) Date: 2004-08-20 15:48 Message: Logged In: YES user_id=254876 I'm not sure that this patch uses the right approach. The correct way to handle this would be for gaim to play sounds for received messages as they are received, rather than when the window is open. This patch just adds an extra sound that plays when the docklet icon changes status (to online_pending). If I get a chance, I'll take a look at implementing this correctly. ---------------------------------------------------------------------- Comment By: Casey Harkins (charkins) Date: 2004-06-29 15:25 Message: Logged In: YES user_id=254876 This cooresponds to RFE #966977 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=982227&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 04:00:23
|
Patches item #1026516, was opened at 2004-09-11 19:59 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1026516&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc (sanmarcos-) Assigned to: Mark Doliner (thekingant) Summary: Add icons & more shortcuts to gaim menus Initial Comment: Simple patch to make the menu more consistent, (applies to newstatus, which had my previous patch). It adds GTK_STOCK icons and a few new shortcuts, to make using gaim faster, and making browsing through menus more intiutive Add Chat => CTL+H Add Group => CTL+G Room List => CTL+R Privacy => CTL+V View System Log => CTL+S I have a doubt about CTL+V, and S, but you guys are free to change them to whatever you want. You can find a screenshot here: http://m4rccd.homelinux.net/files/gaim-menus.png Patch for HEAD(newstatus) attached below. Also, feel free to remove icons & shortcuts that conflict, or hat dont match the menu action. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-13 23:00 Message: Logged In: YES user_id=20979 I accepted the icons for the privacy and room list menu items (and nothing else). The "add chat" menu item already had a menu item. I didn't feel the icon for "view user log" and "view system log" were really associated with the action (not with my set of icons, anyway). And I also didn't think the icon name really went well with log viewing. And I didn't add the shortcut keys because I don't think they'd be used and I think they'd clutter the menu a bit. ---------------------------------------------------------------------- Comment By: Marc (sanmarcos-) Date: 2005-03-06 19:31 Message: Logged In: YES user_id=1107028 This patch is 6 months old. I wont even bother on modifying it to compile on a recent HEAD or oldstatus. So it is up to you. But, the screenshot is here: http://www.jardinpresente.com.ar/files/shots/gaim-menus.png ---------------------------------------------------------------------- Comment By: Etan Reisner (deryni9) Date: 2005-03-05 19:50 Message: Logged In: YES user_id=516184 I can't comment on the icons as I haven't seen them, but I question whether we really want to be giving all these menu items keyboard shortcuts by default rather than just telling people that if they really want the extra shortcuts they should use the gtk on-the-fly accelerator adding feature to get them. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-05 19:29 Message: Logged In: YES user_id=20979 Hmm, I thought I had commented on this, but I guess not. Personally I don't think I ever use these short cuts. Do you? I don't think it's really necessary to have a keyboard short cut for adding a group, for example. How often do people do that? Would people really remember what the keyboard shortcut is for adding a chat? It seems like it would be better to only have shortcuts for things that are used frequently (get info, new IM, etc.) I guess my question is, are you adding these shortcuts simply because they're not there? Or are you adding them because you would use them? I haven't applied the patch and can't comment on what I think about the icons. If you still have that screen shot, could you attach it here? (The link is dead--surely our fault for waiting so long to do anything with this patch) ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2005-02-20 21:14 Message: Logged In: YES user_id=28833 Mark, what do you think of this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1026516&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 23:34:38
|
Patches item #1030437, was opened at 2004-09-18 15:39 Message generated for change (Comment added) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030437&group_id=235 Category: None Group: None >Status: Pending >Resolution: Out of Date Priority: 5 Submitted By: Arun A Tharuvai (aat) Assigned to: Sean Egan (seanegan) Summary: zephyr: misc fixes Initial Comment: Fix Philip Mucci's bug (reported to gaim-devel on the 16th), where malformed (visibility) strings, caused users to be unmessageable and hidden, by normalizing them, and using sane defaults. Fixes CraigD's bug IRC reported on IRC (non-kerberized zephyr users always have the realm "local-realm"), by adding a user-specified "Realm" option string. Also added two new preferences (import from .anyone and import from .zephyr.subs) to go with (export to .anyone and "export to .zephyr.subs"). Since one can now use multiple accounts, most people wouldn't want to use the same buddy lists and chat room lists for both accounts. Added a /topic command to make zephyr use the same command name as the other protocols which have topics. ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-03-13 18:34 Message: Logged In: YES user_id=199625 I'd normally hand-merge old paches that no longer apply cleanly, but so much of this is merely formatting changes, that I can't even tell where there's actually code changes to review. Would you please resubmit a cleaner version? ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2004-09-27 19:18 Message: Logged In: YES user_id=28833 Arun, have you updated the patch? ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2004-09-18 18:02 Message: Logged In: YES user_id=28833 luke@lschiere:~/Documents/gaim/gaim.my$ patch -p1 -i ../patch/gdiff patching file src/protocols/zephyr/zephyr.c Hunk #2 FAILED at 88. Hunk #3 FAILED at 697. Hunk #4 FAILED at 930. Hunk #5 FAILED at 1018. Hunk #6 FAILED at 1100. Hunk #7 FAILED at 1221. Hunk #8 FAILED at 1417. Hunk #9 succeeded at 1443 (offset 11 lines). Hunk #10 FAILED at 1544. Hunk #11 FAILED at 1572. Hunk #12 FAILED at 1603. Hunk #13 succeeded at 1676 (offset 11 lines). Hunk #14 succeeded at 1708 (offset 11 lines). Hunk #15 succeeded at 1745 (offset 11 lines). Hunk #16 FAILED at 1856. Hunk #17 FAILED at 1873. Hunk #18 FAILED at 1908. Hunk #19 FAILED at 2017. Hunk #20 FAILED at 2068. Hunk #21 FAILED at 2408. Hunk #22 succeeded at 2579 (offset 33 lines). Hunk #23 succeeded at 2841 (offset 33 lines). 16 out of 23 hunks FAILED -- saving rejects to file src/protocols/zephyr/zephyr.c.rej patching file src/protocols/zephyr/ZGetSender.c patch unexpectedly ends in middle of line Hunk #1 succeeded at 32 with fuzz 1. luke@lschiere:~/Documents/gaim/gaim.my$ luke@lschiere:~/Documents/gaim/oldstatus$ patch -p1 -i ../patch/gdiff patching file src/protocols/zephyr/zephyr.c patching file src/protocols/zephyr/ZGetSender.c patch unexpectedly ends in middle of line Hunk #1 succeeded at 32 with fuzz 1. luke@lschiere:~/Documents/gaim/oldstatus$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030437&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 23:31:26
|
Patches item #1017319, was opened at 2004-08-26 21:41 Message generated for change (Settings changed) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1017319&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Derrick J Brashear (shadow) Assigned to: Sean Egan (seanegan) Summary: Patches for Zephyr Initial Comment: 1) remove a null pointer deref opportunity in ZRecvNot.c 2) set CONFDIR if not set in internal.h (this may be unnecessary) 3) fix poor grammar in zephyr.c 4) make the "typing" pings not be sent for broadcast messages (generally not done, and entirely not right as was being done in the code) in zephyr.c ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-03-13 18:31 Message: Logged In: YES user_id=199625 Thanks! ---------------------------------------------------------------------- Comment By: Derrick J Brashear (shadow) Date: 2004-08-30 02:23 Message: Logged In: YES user_id=2081 Seems like a no-brainer, don't apply them out of order;-) I'll cvs update and regenerate but it doesn't look like anything in cvs is updated yet, at least on the anonymous side, so I can't see what I need to diff against. ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2004-08-29 21:58 Message: Logged In: YES user_id=28833 i'm sorry, i'm making more work for you. applying zepher patches out of order has broken this again. ---------------------------------------------------------------------- Comment By: Derrick J Brashear (shadow) Date: 2004-08-28 01:42 Message: Logged In: YES user_id=2081 This is generated from a snapshot matching what's in the anonymous cvs tree right now on the head. ---------------------------------------------------------------------- Comment By: Derrick J Brashear (shadow) Date: 2004-08-28 01:40 Message: Logged In: YES user_id=2081 I got: |--- zephyr.c 12 Aug 2004 17:44:10 -0000 1.8 |+++ zephyr.c 27 Aug 2004 01:38:06 -0000 -------------------------- File to patch: gaim/src/protocols/zephyr/zephyr.c patching file gaim/src/protocols/zephyr/zephyr.c Hunk #2 succeeded at 1536 (offset 2 lines). against a fresh CVS checkout. I'll upload a fresh copy of the diff. ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2004-08-27 22:27 Message: Logged In: YES user_id=28833 luke@lschiere:~/Documents/gaim/gaim.commit$ patch -p0 -i ../patch/gaim.diff2 can't find file to patch at input line 8 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: ZRecvNot.c |=================================================================== |RCS file: /cvsroot/adium/libgaim/libgaim/src/protocols/zephyr/ZRecvNot.c,v |retrieving revision 1.2 |diff -u -r1.2 ZRecvNot.c |--- ZRecvNot.c 26 Apr 2004 20:58:42 -0000 1.2 |+++ ZRecvNot.c 27 Aug 2004 01:38:04 -0000 -------------------------- File to patch: src/protocols/zephyr/ZRecvNot.c patching file src/protocols/zephyr/ZRecvNot.c can't find file to patch at input line 25 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: zephyr.c |=================================================================== |RCS file: /cvsroot/adium/libgaim/libgaim/src/protocols/zephyr/zephyr.c,v |retrieving revision 1.8 |diff -u -r1.8 zephyr.c |--- zephyr.c 12 Aug 2004 17:44:10 -0000 1.8 |+++ zephyr.c 27 Aug 2004 01:38:06 -0000 -------------------------- File to patch: src/protocols/zephyr/zephyr.c patching file src/protocols/zephyr/zephyr.c Hunk #1 succeeded at 672 (offset 78 lines). Hunk #2 FAILED at 1612. 1 out of 2 hunks FAILED -- saving rejects to file src/protocols/zephyr/zephyr.c.rej luke@lschiere:~/Documents/gaim/gaim.commit$ ---------------------------------------------------------------------- Comment By: Derrick J Brashear (shadow) Date: 2004-08-26 21:50 Message: Logged In: YES user_id=2081 CONFDIR should be being set by configure, so I removed that ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1017319&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 23:22:56
|
Patches item #680803, was opened at 2003-02-05 06:31 Message generated for change (Comment added) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=680803&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michal (micu) Assigned to: Sean Egan (seanegan) Summary: Gadu-Gadu not working when first server port is blocked Initial Comment: When connecting to a Gadu-Gadu server across a firewall that blocks connections to GG default port (slight above 8000), switching to alternate (443) is not handled properly. I suppose gg_login() function behaves correctly, but this one is not used right now - gaim uses proxy_connect() instead. The quick-and-dirty workaround that I use is to skip first phase of GG connection and connect immediately to 443 (which is not blocked). Below is mini-patch implementing such behaviour (against 0.59.8 but as I far as I can see nothing has changed in GG handling since then). Regards MiCu ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-03-13 18:22 Message: Logged In: YES user_id=199625 Are there any downsides to connecting to this port instead? The comments imply that this is an https port. Unless I'm mistaken, we don't support SSL with GG. Are there any potential problems with that? Also, what about people for whom port 443 is blocked and the default is? This would really be better done by making the port specified in the account editor like it is for every other prpl. Care to take that task on? I'll follow your recommendation, regardless, though. Just because we don't have anyone else interested in GG to consult with. ---------------------------------------------------------------------- Comment By: Michal (micu) Date: 2003-02-05 08:25 Message: Logged In: YES user_id=704973 --- src/protocols/gg/libgg.c.ORIG Sat Dec 21 21:08:19 2002 +++ src/protocols/gg/libgg.c Wed Feb 5 12:23:54 2003 @@ -1011,7 +1011,7 @@ a.s_addr = inet_addr(host); sess->server_ip = a.s_addr; - if ((sess->fd = gg_connect(&a, port, sess->async)) == -1) { + /* if ((sess->fd = gg_connect(&a, port, sess->async)) == -1) { */ gg_debug(GG_DEBUG_MISC, "-- connection failed, trying https connection\n"); if ((sess->fd = gg_connect(&a, GG_HTTPS_PORT, sess->async)) == -1) { gg_debug(GG_DEBUG_MISC, "-- connection failed, errno = %d (%s)\n", errno, strerror(errno)); @@ -1021,7 +1021,7 @@ sess->state = GG_STATE_IDLE; break; } - } + /* } */ sess->state = GG_STATE_CONNECTING_GG; sess->check = GG_CHECK_WRITE; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=680803&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 23:14:01
|
Patches item #982227, was opened at 2004-06-29 16:13 Message generated for change (Comment added) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=982227&group_id=235 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Casey Harkins (charkins) Assigned to: Sean Egan (seanegan) Summary: docklet: play message received sound when message is waiting Initial Comment: This patch to the system tray plugin adds a preference option to play the message received sound when a message is waiting. The sound is played when the status changes to online_pending. ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-03-13 18:13 Message: Logged In: YES user_id=199625 Unless I'm mistaken, this patch will only play a sound the first time a message is received while messages are queued. That's no good. I agree that using the signals mechanism is a good solution. Look at how pounces work for pointers. -s. ---------------------------------------------------------------------- Comment By: Casey Harkins (charkins) Date: 2005-03-08 11:40 Message: Logged In: YES user_id=254876 For the record, I think the correct approach to fixing this and potentially other sound issues is to move all existing gaim sound code into a plugin. Sound events already occur is situations where a signal is being emitted. Using a plugin would allow the sounds to be de-coupled from the interface (the problem in this particular case). It should also simplify the codebase as sound support would be entirely self contained within a plugin instead of littered throughout the core components. I had started work on this a few months ago, but haven't found time to finish it up. I was planning on working on this again soon, unless someone beats me to it. Anyone agree or disagree with moving all sound support into a plugin? ---------------------------------------------------------------------- Comment By: Casey Harkins (charkins) Date: 2004-08-20 16:48 Message: Logged In: YES user_id=254876 I'm not sure that this patch uses the right approach. The correct way to handle this would be for gaim to play sounds for received messages as they are received, rather than when the window is open. This patch just adds an extra sound that plays when the docklet icon changes status (to online_pending). If I get a chance, I'll take a look at implementing this correctly. ---------------------------------------------------------------------- Comment By: Casey Harkins (charkins) Date: 2004-06-29 16:25 Message: Logged In: YES user_id=254876 This cooresponds to RFE #966977 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=982227&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 21:37:15
|
Patches item #1161774, was opened at 2005-03-11 19:55 Message generated for change (Settings changed) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 Category: newfeature Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Hassan (mickeynoear) Assigned to: Sean Egan (seanegan) Summary: Change Buddy Icon in Conversation window Initial Comment: I have seen many requests for this. Stolen from gtkaccount.c shamelessly: - icon_select_cb and related callbacks wich are part of the fileselector 'add/modify account' dialog. modified in gtkconv.c : - added a 'Change Buddy Icon..' under the menu Options, which triggers icon_select_cb This patch also includes an appearance change in the Conversation Window menu. The changes are: - moved menu items from Conversation menu list that are related to contacts into a separate menu list ( named Contact ). - moved menu items from Conversation menu list that are related to history into a separate menu list ( named Contact ). -shuffled menu items according to their group, like: original : Alias, Block, Remove modified to : Warn, Block, Remove original: Send File, Add Buddy Pounce, Get Info, Warn modified to : Alias, Get Info, Add Buddy Pounce The changes were done according to my opinion/preference. Take a look and abandon the idea if it looks ugly =P. ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-03-13 16:37 Message: Logged In: YES user_id=199625 And many more will find it unintuitive to change your own buddy icon in a conversation with another user. We do need to move where we set the buddy icon, but the conversation window is not a good place for it. ---------------------------------------------------------------------- Comment By: Hassan (mickeynoear) Date: 2005-03-13 16:06 Message: Logged In: YES user_id=1187289 I think you have the wrong idea mate :P This Change Buddy Icon option functions just like the other one in Accounts->Add/Modify-> Buddy Icon. It changes *user* buddy icon as seen by other people, not change a buddy's icon as displayed by the user. Many people find it unintuitive to go to the Accounts window and open Add/Modify dialog ... to only change the icon used. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-13 12:14 Message: Logged In: YES user_id=20979 This patch is backwards, right? Does this patch let the Gaim user choose the buddy icon that is displayed for other people? I think I'm against that feature... it seems like it wouldn't be used by a lot of people, would make things more complicated, and would confuse some people. But I don't have a real strong opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 21:06:26
|
Patches item #1161774, was opened at 2005-03-12 00:55 Message generated for change (Comment added) made by mickeynoear You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 Category: newfeature Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hassan (mickeynoear) Assigned to: Sean Egan (seanegan) Summary: Change Buddy Icon in Conversation window Initial Comment: I have seen many requests for this. Stolen from gtkaccount.c shamelessly: - icon_select_cb and related callbacks wich are part of the fileselector 'add/modify account' dialog. modified in gtkconv.c : - added a 'Change Buddy Icon..' under the menu Options, which triggers icon_select_cb This patch also includes an appearance change in the Conversation Window menu. The changes are: - moved menu items from Conversation menu list that are related to contacts into a separate menu list ( named Contact ). - moved menu items from Conversation menu list that are related to history into a separate menu list ( named Contact ). -shuffled menu items according to their group, like: original : Alias, Block, Remove modified to : Warn, Block, Remove original: Send File, Add Buddy Pounce, Get Info, Warn modified to : Alias, Get Info, Add Buddy Pounce The changes were done according to my opinion/preference. Take a look and abandon the idea if it looks ugly =P. ---------------------------------------------------------------------- >Comment By: Hassan (mickeynoear) Date: 2005-03-13 21:06 Message: Logged In: YES user_id=1187289 I think you have the wrong idea mate :P This Change Buddy Icon option functions just like the other one in Accounts->Add/Modify-> Buddy Icon. It changes *user* buddy icon as seen by other people, not change a buddy's icon as displayed by the user. Many people find it unintuitive to go to the Accounts window and open Add/Modify dialog ... to only change the icon used. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-13 17:14 Message: Logged In: YES user_id=20979 This patch is backwards, right? Does this patch let the Gaim user choose the buddy icon that is displayed for other people? I think I'm against that feature... it seems like it wouldn't be used by a lot of people, would make things more complicated, and would confuse some people. But I don't have a real strong opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 18:05:55
|
Patches item #1161777, was opened at 2005-03-11 20:07 Message generated for change (Comment added) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Hassan (mickeynoear) Assigned to: Sean Egan (seanegan) Summary: Truncate Long Friendly Name Initial Comment: Probably this will get moved to 'Rejected Patches' section. But I'll send it here for review anyway. Changed function gaim_gtk_blist_get_name_markup in gtkblist.c so that it will truncate long friendly names in the buddy list. The truncate length is determined by an option in the preference window Changed function max_name_enter_callback in gtkprefs.c to add a textbox and labels where the user can specify the maximum length of friendly name before starting to truncate it. ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-03-13 13:05 Message: Logged In: YES user_id=199625 Gaim 2.0.0 + GTK+ 2.6 = Automatic ellipsization according to buddy list width. ---------------------------------------------------------------------- Comment By: Stu Tomlinson (nosnilmot) Date: 2005-03-13 13:02 Message: Logged In: YES user_id=309779 FYI, this is not UTF-8 safe and I agree with Mark ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-13 12:05 Message: Logged In: YES user_id=20979 FYI I'm against committing this. The ellipsizing feature in gtk 2.6 eliminates the need for client-implemented truncation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 18:02:34
|
Patches item #1161777, was opened at 2005-03-11 20:07 Message generated for change (Comment added) made by nosnilmot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hassan (mickeynoear) Assigned to: Sean Egan (seanegan) Summary: Truncate Long Friendly Name Initial Comment: Probably this will get moved to 'Rejected Patches' section. But I'll send it here for review anyway. Changed function gaim_gtk_blist_get_name_markup in gtkblist.c so that it will truncate long friendly names in the buddy list. The truncate length is determined by an option in the preference window Changed function max_name_enter_callback in gtkprefs.c to add a textbox and labels where the user can specify the maximum length of friendly name before starting to truncate it. ---------------------------------------------------------------------- >Comment By: Stu Tomlinson (nosnilmot) Date: 2005-03-13 13:02 Message: Logged In: YES user_id=309779 FYI, this is not UTF-8 safe and I agree with Mark ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-13 12:05 Message: Logged In: YES user_id=20979 FYI I'm against committing this. The ellipsizing feature in gtk 2.6 eliminates the need for client-implemented truncation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 17:14:39
|
Patches item #1161774, was opened at 2005-03-11 19:55 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 Category: newfeature Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hassan (mickeynoear) Assigned to: Sean Egan (seanegan) Summary: Change Buddy Icon in Conversation window Initial Comment: I have seen many requests for this. Stolen from gtkaccount.c shamelessly: - icon_select_cb and related callbacks wich are part of the fileselector 'add/modify account' dialog. modified in gtkconv.c : - added a 'Change Buddy Icon..' under the menu Options, which triggers icon_select_cb This patch also includes an appearance change in the Conversation Window menu. The changes are: - moved menu items from Conversation menu list that are related to contacts into a separate menu list ( named Contact ). - moved menu items from Conversation menu list that are related to history into a separate menu list ( named Contact ). -shuffled menu items according to their group, like: original : Alias, Block, Remove modified to : Warn, Block, Remove original: Send File, Add Buddy Pounce, Get Info, Warn modified to : Alias, Get Info, Add Buddy Pounce The changes were done according to my opinion/preference. Take a look and abandon the idea if it looks ugly =P. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-13 12:14 Message: Logged In: YES user_id=20979 This patch is backwards, right? Does this patch let the Gaim user choose the buddy icon that is displayed for other people? I think I'm against that feature... it seems like it wouldn't be used by a lot of people, would make things more complicated, and would confuse some people. But I don't have a real strong opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 17:05:14
|
Patches item #1161777, was opened at 2005-03-11 20:07 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hassan (mickeynoear) Assigned to: Sean Egan (seanegan) Summary: Truncate Long Friendly Name Initial Comment: Probably this will get moved to 'Rejected Patches' section. But I'll send it here for review anyway. Changed function gaim_gtk_blist_get_name_markup in gtkblist.c so that it will truncate long friendly names in the buddy list. The truncate length is determined by an option in the preference window Changed function max_name_enter_callback in gtkprefs.c to add a textbox and labels where the user can specify the maximum length of friendly name before starting to truncate it. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-13 12:05 Message: Logged In: YES user_id=20979 FYI I'm against committing this. The ellipsizing feature in gtk 2.6 eliminates the need for client-implemented truncation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 15:30:19
|
Patches item #1161777, was opened at 2005-03-11 20:07 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hassan (mickeynoear) >Assigned to: Sean Egan (seanegan) Summary: Truncate Long Friendly Name Initial Comment: Probably this will get moved to 'Rejected Patches' section. But I'll send it here for review anyway. Changed function gaim_gtk_blist_get_name_markup in gtkblist.c so that it will truncate long friendly names in the buddy list. The truncate length is determined by an option in the preference window Changed function max_name_enter_callback in gtkprefs.c to add a textbox and labels where the user can specify the maximum length of friendly name before starting to truncate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161777&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 15:30:09
|
Patches item #1161774, was opened at 2005-03-11 19:55 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 Category: newfeature Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hassan (mickeynoear) >Assigned to: Sean Egan (seanegan) Summary: Change Buddy Icon in Conversation window Initial Comment: I have seen many requests for this. Stolen from gtkaccount.c shamelessly: - icon_select_cb and related callbacks wich are part of the fileselector 'add/modify account' dialog. modified in gtkconv.c : - added a 'Change Buddy Icon..' under the menu Options, which triggers icon_select_cb This patch also includes an appearance change in the Conversation Window menu. The changes are: - moved menu items from Conversation menu list that are related to contacts into a separate menu list ( named Contact ). - moved menu items from Conversation menu list that are related to history into a separate menu list ( named Contact ). -shuffled menu items according to their group, like: original : Alias, Block, Remove modified to : Warn, Block, Remove original: Send File, Add Buddy Pounce, Get Info, Warn modified to : Alias, Get Info, Add Buddy Pounce The changes were done according to my opinion/preference. Take a look and abandon the idea if it looks ugly =P. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1161774&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 07:13:43
|
Patches item #1162195, was opened at 2005-03-12 18:15 Message generated for change (Comment added) made by coderjeff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162195&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Allen (mojavelinux) Assigned to: Nobody/Anonymous (nobody) Summary: im received changes docklet icon Initial Comment: In the v1_1_4 branch of gaim, the docklet plugin gives the option to "hide new messages while away," which queues the messages and changes the icon of the docklet to a gaim man with an envelop emblem. While this feature is helpful, it doesn't help with conversations while active. This patch changes the docklet when a new im is received. It is relevant only to the 1_1_4 branch since the docklet plugin has changed drastically in HEAD. Scenario: The gaim conversation window is open but on a seperate Linux desktop (or perhaps set not to raise or notify on events). When a new message arrives, there is no visual indicator that the IM window received activity (the URGENT doesn't seem to work in this case). Solution: This patch changes the docklet icon to the gaim man with the envelop emblem when a new IM is received. It will change back to normal when a reply is sent or when clicking on the docklet icon. ---------------------------------------------------------------------- Comment By: Jeffery To (coderjeff) Date: 2005-03-13 02:13 Message: Logged In: YES user_id=1089354 Maybe Guifications <http://guifications.sourceforge.net/> can fix your message notification problem. ---------------------------------------------------------------------- Comment By: Dan Allen (mojavelinux) Date: 2005-03-12 18:20 Message: Logged In: YES user_id=1088017 Seems the motivation of my docklet patch has also been captured in the following notification patch: https://sourceforge.net/tracker/index.php?func=detail&aid=694856&group_id=235&atid=300235 The problem I am having is that I keep missing new IMs in open windows and the person contacting me gets pissed. I don't enable "raise on events" because it keeps jumping in my face when I am trying work (they end up getting portions of my java code). Essentially, I want to know that someone has sent me an IM, but I don't want it to get in the way. Additionally, sound is not available (which is fairly common in a work environment). The docklet is the perfect location to attach this notification. Without this patch, there is no such way to accomplish this in gaim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162195&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-12 23:20:21
|
Patches item #1162195, was opened at 2005-03-12 18:15 Message generated for change (Comment added) made by mojavelinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162195&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Allen (mojavelinux) Assigned to: Nobody/Anonymous (nobody) Summary: im received changes docklet icon Initial Comment: In the v1_1_4 branch of gaim, the docklet plugin gives the option to "hide new messages while away," which queues the messages and changes the icon of the docklet to a gaim man with an envelop emblem. While this feature is helpful, it doesn't help with conversations while active. This patch changes the docklet when a new im is received. It is relevant only to the 1_1_4 branch since the docklet plugin has changed drastically in HEAD. Scenario: The gaim conversation window is open but on a seperate Linux desktop (or perhaps set not to raise or notify on events). When a new message arrives, there is no visual indicator that the IM window received activity (the URGENT doesn't seem to work in this case). Solution: This patch changes the docklet icon to the gaim man with the envelop emblem when a new IM is received. It will change back to normal when a reply is sent or when clicking on the docklet icon. ---------------------------------------------------------------------- >Comment By: Dan Allen (mojavelinux) Date: 2005-03-12 18:20 Message: Logged In: YES user_id=1088017 Seems the motivation of my docklet patch has also been captured in the following notification patch: https://sourceforge.net/tracker/index.php?func=detail&aid=694856&group_id=235&atid=300235 The problem I am having is that I keep missing new IMs in open windows and the person contacting me gets pissed. I don't enable "raise on events" because it keeps jumping in my face when I am trying work (they end up getting portions of my java code). Essentially, I want to know that someone has sent me an IM, but I don't want it to get in the way. Additionally, sound is not available (which is fairly common in a work environment). The docklet is the perfect location to attach this notification. Without this patch, there is no such way to accomplish this in gaim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162195&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-12 23:15:19
|
Patches item #1162195, was opened at 2005-03-12 18:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162195&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Allen (mojavelinux) Assigned to: Nobody/Anonymous (nobody) Summary: im received changes docklet icon Initial Comment: In the v1_1_4 branch of gaim, the docklet plugin gives the option to "hide new messages while away," which queues the messages and changes the icon of the docklet to a gaim man with an envelop emblem. While this feature is helpful, it doesn't help with conversations while active. This patch changes the docklet when a new im is received. It is relevant only to the 1_1_4 branch since the docklet plugin has changed drastically in HEAD. Scenario: The gaim conversation window is open but on a seperate Linux desktop (or perhaps set not to raise or notify on events). When a new message arrives, there is no visual indicator that the IM window received activity (the URGENT doesn't seem to work in this case). Solution: This patch changes the docklet icon to the gaim man with the envelop emblem when a new IM is received. It will change back to normal when a reply is sent or when clicking on the docklet icon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162195&group_id=235 |
3 messages has been excluded from this view by a project administrator.
