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-06-21 05:54:54
|
Patches item #1224485, was opened at 2005-06-20 19:21 Message generated for change (Comment added) made by behdad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224485&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Behdad Esfahbod (behdad) Assigned to: Mark Doliner (thekingant) Summary: Simple build fixes Initial Comment: Attached is a simple patch to make giam build on C compilers that do not allow variable declaration after other statements. ---------------------------------------------------------------------- >Comment By: Behdad Esfahbod (behdad) Date: 2005-06-21 01:54 Message: Logged In: YES user_id=47601 Thanks. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-21 01:45 Message: Logged In: YES user_id=156487 This patch can be closed with Resolution: Fixed. This is already fixed in both oldstatus and HEAD. I just double-checked it in the source for both trees. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224485&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-21 05:49:44
|
Patches item #1224610, was opened at 2005-06-21 00:49 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=1224610&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Nobody/Anonymous (nobody) Summary: Buddy Icons Not Being Removed Initial Comment: Buddy icon cache files are removed when replacing icons but not when unsetting the icon. This patch corrects that. I think this fixes the only case where buddy icon cache files are not being deleted when they should be. I'd like to hear if anyone is seeing otherwise after this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224610&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-21 05:45:08
|
Patches item #1224485, was opened at 2005-06-20 18:21 Message generated for change (Comment added) made by rlaager You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224485&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Behdad Esfahbod (behdad) Assigned to: Mark Doliner (thekingant) Summary: Simple build fixes Initial Comment: Attached is a simple patch to make giam build on C compilers that do not allow variable declaration after other statements. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-21 00:45 Message: Logged In: YES user_id=156487 This patch can be closed with Resolution: Fixed. This is already fixed in both oldstatus and HEAD. I just double-checked it in the source for both trees. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224485&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-21 02:39:39
|
Patches item #1223021, was opened at 2005-06-18 02:35 Message generated for change (Comment added) made by jroth2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1223021&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Roth (jroth2) Assigned to: Nobody/Anonymous (nobody) Summary: fixes bug #1222552 Initial Comment: As described in bug report #1222552, gaim will disconnect the current msn session and corrupt blist.xml when you try to add an msn screenname with a space in it (e.g. "foo ba...@ho..."). This patch adds a check to userlist.c in the form of a three line if statement if(strrchr(who, " ") == NULL) { gaim_debug("msn", "MSN screennames cannot contain spaces"); return; } ---------------------------------------------------------------------- >Comment By: Jason Roth (jroth2) Date: 2005-06-21 02:39 Message: Logged In: YES user_id=1298163 yeah, sorry, i misread my man page. strchr(who, " ") != NULL is better. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-19 04:25 Message: Logged In: YES user_id=156487 My man page says: The strchr() and strrchr() functions return a pointer to the matched character or NULL if the character is not found. I also don't see the point of using strrchr. Wouldn't strchr do? Therefore, shouldn't this be something like: if (strchr(who, " ") != NULL) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1223021&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-21 01:50:58
|
Patches item #1224555, was opened at 2005-06-21 01:50 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=1224555&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Enix (enix) Assigned to: Nobody/Anonymous (nobody) Summary: [HEAD, Oldstatus] Tooltip appears over gtkblist context menu Initial Comment: When the gtkblist context menu is displayed, the tooltip timeout is not removed. This results in the tooltip displaying over the context menu when the timeout occurs. Included is a short patch to remove the timeout before displaying the context menu. Applies against HEAD and Oldstatus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224555&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 23:59:19
|
Patches item #1224485, was opened at 2005-06-20 19:21 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224485&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Behdad Esfahbod (behdad) >Assigned to: Mark Doliner (thekingant) Summary: Simple build fixes Initial Comment: Attached is a simple patch to make giam build on C compilers that do not allow variable declaration after other statements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224485&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 20:56:28
|
Patches item #1224386, was opened at 2005-06-20 16:21 Message generated for change (Comment added) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224386&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Levi Bard (tak_tak) Assigned to: Nobody/Anonymous (nobody) Summary: IRC keepalive ping Initial Comment: Patch to ping IRC servers at arbitrary intervals in order to prevent connections from dropping. ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-06-20 16:56 Message: Logged In: YES user_id=199625 This function has no need to be configurable; once a minute should be plenty often enough to keep a NAT tunnel open, and if not the feature should be globally configurable so that AIM server pings happen more frequently as well. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-20 16:46 Message: Logged In: YES user_id=644705 The existing ison functionality isn't at adjustable intervals, and I thought it would be better to allow increasing the frequency of a single ping rather than whatever arbitrary number of buddies the user happens to have for each connection. ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-20 16:26 Message: Logged In: YES user_id=199625 This is great, but implemented wrong. Find the existing IRC keepalive function, currently used solely to poll the buddy list with a RNG command, and if there is no buddy list, send a PNG command instead. -s. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224386&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 20:46:09
|
Patches item #1224386, was opened at 2005-06-20 16:21 Message generated for change (Comment added) made by tak_tak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224386&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Levi Bard (tak_tak) Assigned to: Nobody/Anonymous (nobody) Summary: IRC keepalive ping Initial Comment: Patch to ping IRC servers at arbitrary intervals in order to prevent connections from dropping. ---------------------------------------------------------------------- >Comment By: Levi Bard (tak_tak) Date: 2005-06-20 16:46 Message: Logged In: YES user_id=644705 The existing ison functionality isn't at adjustable intervals, and I thought it would be better to allow increasing the frequency of a single ping rather than whatever arbitrary number of buddies the user happens to have for each connection. ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-20 16:26 Message: Logged In: YES user_id=199625 This is great, but implemented wrong. Find the existing IRC keepalive function, currently used solely to poll the buddy list with a RNG command, and if there is no buddy list, send a PNG command instead. -s. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224386&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 20:26:11
|
Patches item #1224386, was opened at 2005-06-20 16:21 Message generated for change (Comment added) made by seanegan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224386&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Levi Bard (tak_tak) Assigned to: Nobody/Anonymous (nobody) Summary: IRC keepalive ping Initial Comment: Patch to ping IRC servers at arbitrary intervals in order to prevent connections from dropping. ---------------------------------------------------------------------- >Comment By: Sean Egan (seanegan) Date: 2005-06-20 16:26 Message: Logged In: YES user_id=199625 This is great, but implemented wrong. Find the existing IRC keepalive function, currently used solely to poll the buddy list with a RNG command, and if there is no buddy list, send a PNG command instead. -s. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224386&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 20:21:59
|
Patches item #1224386, was opened at 2005-06-20 16:21 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=1224386&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Levi Bard (tak_tak) Assigned to: Nobody/Anonymous (nobody) Summary: IRC keepalive ping Initial Comment: Patch to ping IRC servers at arbitrary intervals in order to prevent connections from dropping. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224386&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 17:21:31
|
Patches item #1222377, was opened at 2005-06-17 00:39 Message generated for change (Comment added) made by evands You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222377&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evan Schoenberg (evands) Assigned to: Mark Doliner (thekingant) Summary: [OSCAR] Improve buddy icon retrieval Initial Comment: When retrieving the userinfo and then using that data to request a buddy icon, a value in Gaim was previously hardcoded to 0x01. It's called "number" in locate.c... seems that it is unclear what exactly it means. In any vase, buddy icon checksums had to have a "number" of 0x01. However, 0x00 is also a valid "number." Fire calls this field iconcsumtype, so I've used that name for it. iconcsumtype is passed back to aim_bart_request() where it is used [it will be either 0x00 or 0x01, whereas Gaim was always assuming it was 0x01]. The result: Certain buddy icons which Gaim previously could not retrieve are now retrieveable. I believe that these are primarily coming from old clients; a clear example (and my test case for finding this fix) is the AOLYellowPages buddy, run by the AIM server. Before the patch, no icon; with the patch, the icon as properly retrieved by the official client. This patch is ported... sideported?... from Fire's modified libfaim; I noticed Fire was doing a better job retrieving buddy icons than Gaim was, and hunted down the cause. Applies against oldstatus and HEAD. ---------------------------------------------------------------------- >Comment By: Evan Schoenberg (evands) Date: 2005-06-20 12:21 Message: Logged In: YES user_id=669684 Clarification: I meant certain other icons, not all other icons. Expansion: This patch also lets Gaim retrieve icons from users of recent versions of AOL for Windows, which was not possible before. ---------------------------------------------------------------------- Comment By: Evan Schoenberg (evands) Date: 2005-06-19 13:13 Message: Logged In: YES user_id=669684 Hmm... further testing shows that this seems to cause OTHER icons not to appear properly; Gaim gets an icon, but it is blank. I'll investigate this further... any suggestions as to the cause would be much appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222377&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 15:37:48
|
Patches item #1224108, was opened at 2005-06-20 18:12 Message generated for change (Settings changed) made by sadrul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224108&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Sadrul H C (sadrul) Assigned to: Nobody/Anonymous (nobody) Summary: Improving screenname accessibility Initial Comment: Hello. This patch comes with a few tweaks in the request-dialog system. Currently some of the dialogs (eg. `Get User Info', `New Instant Message' etc) have an auto-complete field for screennames of buddies. This auto-complete list contains the list of buddies from the accounts which are connected. However, it may be necessary to get the list of screennames from all of the accounts (even the disconnected/unconnected ones). For example, in `View User Log' dialog, it is possible to select a disconnected account, but the auto-complete list for the screenames doesn't contain the names from the disconnected accounts. This patch enables for that to happen. Some plugins also may need to have such an auto-complete list for an entry. This functionality can also be added to the `New Buddy Pounce' dialog, which currently doesn't have any auto-completion support. So I have `non-static'-ed a function so that plugins can use that function without repeating the work which is already there in the core. This patch is against the oldstatus. If this does seem like an appropriate way of doing things, I think I can make necessary changes for it to work with HEAD as well. -- Adil ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-20 21:07 Message: Logged In: YES user_id=156487 The bulk of this patch is to make autocompletion of offline accounts possible. I've already done that (in a bit cleaner way) as part of patch 1180490. As for making this a public API function... This patch doesn't name the function properly, nor add documentation. As it stands, this isn't something ready to be accepted. sadrul: You should consider withdrawing this patch and doing the development on HEAD like I've just mentioned. That way you can apply my patch first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224108&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 15:07:51
|
Patches item #1224108, was opened at 2005-06-20 07:12 Message generated for change (Comment added) made by rlaager You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224108&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sadrul H C (sadrul) Assigned to: Nobody/Anonymous (nobody) Summary: Improving screenname accessibility Initial Comment: Hello. This patch comes with a few tweaks in the request-dialog system. Currently some of the dialogs (eg. `Get User Info', `New Instant Message' etc) have an auto-complete field for screennames of buddies. This auto-complete list contains the list of buddies from the accounts which are connected. However, it may be necessary to get the list of screennames from all of the accounts (even the disconnected/unconnected ones). For example, in `View User Log' dialog, it is possible to select a disconnected account, but the auto-complete list for the screenames doesn't contain the names from the disconnected accounts. This patch enables for that to happen. Some plugins also may need to have such an auto-complete list for an entry. This functionality can also be added to the `New Buddy Pounce' dialog, which currently doesn't have any auto-completion support. So I have `non-static'-ed a function so that plugins can use that function without repeating the work which is already there in the core. This patch is against the oldstatus. If this does seem like an appropriate way of doing things, I think I can make necessary changes for it to work with HEAD as well. -- Adil ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-20 10:07 Message: Logged In: YES user_id=156487 The bulk of this patch is to make autocompletion of offline accounts possible. I've already done that (in a bit cleaner way) as part of patch 1180490. As for making this a public API function... This patch doesn't name the function properly, nor add documentation. As it stands, this isn't something ready to be accepted. sadrul: You should consider withdrawing this patch and doing the development on HEAD like I've just mentioned. That way you can apply my patch first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224108&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 12:12:53
|
Patches item #1224108, was opened at 2005-06-20 18:12 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=1224108&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sadrul H C (sadrul) Assigned to: Nobody/Anonymous (nobody) Summary: Improving screenname accessibility Initial Comment: Hello. This patch comes with a few tweaks in the request-dialog system. Currently some of the dialogs (eg. `Get User Info', `New Instant Message' etc) have an auto-complete field for screennames of buddies. This auto-complete list contains the list of buddies from the accounts which are connected. However, it may be necessary to get the list of screennames from all of the accounts (even the disconnected/unconnected ones). For example, in `View User Log' dialog, it is possible to select a disconnected account, but the auto-complete list for the screenames doesn't contain the names from the disconnected accounts. This patch enables for that to happen. Some plugins also may need to have such an auto-complete list for an entry. This functionality can also be added to the `New Buddy Pounce' dialog, which currently doesn't have any auto-completion support. So I have `non-static'-ed a function so that plugins can use that function without repeating the work which is already there in the core. This patch is against the oldstatus. If this does seem like an appropriate way of doing things, I think I can make necessary changes for it to work with HEAD as well. -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1224108&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 08:04:01
|
Patches item #1222664, was opened at 2005-06-17 14:34 Message generated for change (Comment added) made by gabbath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222664&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabbath (gabbath) Assigned to: Etan Reisner (deryni9) Summary: new signal: buddy-changed-status Initial Comment: i'm really sorry, i couldn't diff against the cvs because i'm probably doing something wrong. i followed the directions for downloading it but from the autogen.sh part it won't work... i'll try again later maybe. anyway, this isn't much, it's a really simple signal, but i find it very useful. also, it can probably be adapted quite easily for the cvs, as it just adds one or two lines of code :)) Changes: src/blist.c -> add "buddy-changed-status" plugins/signals-test.c -> test "buddy-changed-status" Description: the "buddy-changed-status" signal takes place whenever a specified buddy updates his/her status, status text or idle time. i found it very useful for a plugin that i made which shows the buddy's current status and idle time right in the IM window... and it might have other uses too. anyway, "buddy-away" and "buddy-back" aren't enough for this as yahoo (for instance) allows status messages even when you're not away, so instead of refreshing automatically every 30secs, i preferred to add this useful signal (for idle update i suppose one can use "buddy-idle-updated", but i thought it should actually engulf - as its name suggests - all the stuff related to a buddy's status). it's a bit weird that it gets emitted several times when a status changes, not just once, but i suppose it's because when a buddy changes his/her status, it goes from away to back and then away again or something. ---------------------------------------------------------------------- >Comment By: Gabbath (gabbath) Date: 2005-06-20 08:03 Message: Logged In: YES user_id=1298580 ok, then, i'll see what i can do to make it in-state. the bad part is i've got some exams coming and can't take care of it right away, but be certain that in a few weeks i'll come up with something. i'm sorry if i'm a bit new to this. what exactly are HEAD and oldstatus? (i have to remind you that i couldn't get gaim from the cvs following the directions on the site) i think i know but i'm not too sure. if you wish to respond to this, perhaps it would be better if you sent me an email so as not to fill up space here with off-topic stuff. cheers ---------------------------------------------------------------------- Comment By: Etan Reisner (deryni9) Date: 2005-06-20 03:47 Message: Logged In: YES user_id=516184 I would say that if you want a signal which fires for in-state changes then that's fine, but it probably shouldn't fire for inter-state changes. I'd sooner accept this sort of patch if it was a completely supplementary signal. A similar signal/patch for HEAD would also be useful. ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-19 10:40 Message: Logged In: YES user_id=1298580 bleeter, i have fedora core 3 if it helps in any way. i just follow the exact directions on your site, but they don't work from the autogen.sh part. i've double checked all the packages listed there but it still won't work... any tips? oh, and to be on topic: any comments on the new signal idea? :) ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-06-19 08:10 Message: Logged In: YES user_id=407708 You seem to be having problems pulling from CVS (as indicated with all your patches). Maybe you're not getting the 'oldstatus', and instead the HEAD (which is the very unreliable Gaim2) ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-18 08:49 Message: Logged In: YES user_id=1298580 >It would seem that this patch is basically just for catching >when a buddy switches from one away state to another away >state, yes? well, not exactly, some protocols (like yahoo) can have states without actually being away, like the song they're playing in, say, winamp. and they still appear available. now buddy-away, buddy-back etc don't actually catch these signals as the contact is never really away... none of the signals do. that's why i defined it. oh, and... i have to correct something, it doesn't take place when buddy-idle-updated (my bad, sorry). perhaps i should not have it emit when the buddy goes idle and back... that was just for the sake of completenes, so you can ignore the changes made to gaim_blist_update_buddy_idle ---------------------------------------------------------------------- Comment By: Etan Reisner (deryni9) Date: 2005-06-17 22:30 Message: Logged In: YES user_id=516184 It would seem that this patch is basically just for catching when a buddy switches from one away state to another away state, yes? If that's the case is there a reason you decided to have it duplicate buddy-away, buddy-back, buddy-idle, and buddy-idle-updated rather than just adding a buddy-away-updated? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222664&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 05:36:36
|
Patches item #1223909, was opened at 2005-06-20 00:36 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=1223909&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Nobody/Anonymous (nobody) Summary: New Accessor Method: gaim_gtk_blist_node_is_contact_expanded Initial Comment: This patch adds a new accessor method that tells whether or not a blist node is part of an expanded contact. This was necessary to get proper right-click behavior for a plugin I wrote. The plugin is gaim-album and it archives buddy icons. I wanted the View Buddy Icons menu item to behave like View Log does in HEAD. It always gives you the icons for the entire contact, except when you right-click on a buddy that's in an expanded contact, in which case you get the icons for just that buddy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1223909&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 03:47:33
|
Patches item #1222664, was opened at 2005-06-17 10:34 Message generated for change (Comment added) made by deryni9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222664&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabbath (gabbath) Assigned to: Etan Reisner (deryni9) Summary: new signal: buddy-changed-status Initial Comment: i'm really sorry, i couldn't diff against the cvs because i'm probably doing something wrong. i followed the directions for downloading it but from the autogen.sh part it won't work... i'll try again later maybe. anyway, this isn't much, it's a really simple signal, but i find it very useful. also, it can probably be adapted quite easily for the cvs, as it just adds one or two lines of code :)) Changes: src/blist.c -> add "buddy-changed-status" plugins/signals-test.c -> test "buddy-changed-status" Description: the "buddy-changed-status" signal takes place whenever a specified buddy updates his/her status, status text or idle time. i found it very useful for a plugin that i made which shows the buddy's current status and idle time right in the IM window... and it might have other uses too. anyway, "buddy-away" and "buddy-back" aren't enough for this as yahoo (for instance) allows status messages even when you're not away, so instead of refreshing automatically every 30secs, i preferred to add this useful signal (for idle update i suppose one can use "buddy-idle-updated", but i thought it should actually engulf - as its name suggests - all the stuff related to a buddy's status). it's a bit weird that it gets emitted several times when a status changes, not just once, but i suppose it's because when a buddy changes his/her status, it goes from away to back and then away again or something. ---------------------------------------------------------------------- >Comment By: Etan Reisner (deryni9) Date: 2005-06-19 23:47 Message: Logged In: YES user_id=516184 I would say that if you want a signal which fires for in-state changes then that's fine, but it probably shouldn't fire for inter-state changes. I'd sooner accept this sort of patch if it was a completely supplementary signal. A similar signal/patch for HEAD would also be useful. ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-19 06:40 Message: Logged In: YES user_id=1298580 bleeter, i have fedora core 3 if it helps in any way. i just follow the exact directions on your site, but they don't work from the autogen.sh part. i've double checked all the packages listed there but it still won't work... any tips? oh, and to be on topic: any comments on the new signal idea? :) ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-06-19 04:10 Message: Logged In: YES user_id=407708 You seem to be having problems pulling from CVS (as indicated with all your patches). Maybe you're not getting the 'oldstatus', and instead the HEAD (which is the very unreliable Gaim2) ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-18 04:49 Message: Logged In: YES user_id=1298580 >It would seem that this patch is basically just for catching >when a buddy switches from one away state to another away >state, yes? well, not exactly, some protocols (like yahoo) can have states without actually being away, like the song they're playing in, say, winamp. and they still appear available. now buddy-away, buddy-back etc don't actually catch these signals as the contact is never really away... none of the signals do. that's why i defined it. oh, and... i have to correct something, it doesn't take place when buddy-idle-updated (my bad, sorry). perhaps i should not have it emit when the buddy goes idle and back... that was just for the sake of completenes, so you can ignore the changes made to gaim_blist_update_buddy_idle ---------------------------------------------------------------------- Comment By: Etan Reisner (deryni9) Date: 2005-06-17 18:30 Message: Logged In: YES user_id=516184 It would seem that this patch is basically just for catching when a buddy switches from one away state to another away state, yes? If that's the case is there a reason you decided to have it duplicate buddy-away, buddy-back, buddy-idle, and buddy-idle-updated rather than just adding a buddy-away-updated? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222664&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 18:13:38
|
Patches item #1222377, was opened at 2005-06-17 00:39 Message generated for change (Comment added) made by evands You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222377&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evan Schoenberg (evands) Assigned to: Mark Doliner (thekingant) Summary: [OSCAR] Improve buddy icon retrieval Initial Comment: When retrieving the userinfo and then using that data to request a buddy icon, a value in Gaim was previously hardcoded to 0x01. It's called "number" in locate.c... seems that it is unclear what exactly it means. In any vase, buddy icon checksums had to have a "number" of 0x01. However, 0x00 is also a valid "number." Fire calls this field iconcsumtype, so I've used that name for it. iconcsumtype is passed back to aim_bart_request() where it is used [it will be either 0x00 or 0x01, whereas Gaim was always assuming it was 0x01]. The result: Certain buddy icons which Gaim previously could not retrieve are now retrieveable. I believe that these are primarily coming from old clients; a clear example (and my test case for finding this fix) is the AOLYellowPages buddy, run by the AIM server. Before the patch, no icon; with the patch, the icon as properly retrieved by the official client. This patch is ported... sideported?... from Fire's modified libfaim; I noticed Fire was doing a better job retrieving buddy icons than Gaim was, and hunted down the cause. Applies against oldstatus and HEAD. ---------------------------------------------------------------------- >Comment By: Evan Schoenberg (evands) Date: 2005-06-19 13:13 Message: Logged In: YES user_id=669684 Hmm... further testing shows that this seems to cause OTHER icons not to appear properly; Gaim gets an icon, but it is blank. I'll investigate this further... any suggestions as to the cause would be much appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222377&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 14:02:07
|
Patches item #1218914, was opened at 2005-06-12 03:04 Message generated for change (Comment added) made by sadrul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1218914&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sadrul H C (sadrul) Assigned to: Nobody/Anonymous (nobody) Summary: Backporting buddy-icon-cached-signal and buddy-icon-extn Initial Comment: backporting two seperate patches ([ 1211718 ] "Set Extension for Saving Buddy Icons" and [ 1197984 ] "Add a Buddy Icon Cached Signal" : both by rlaager] for oldstatus (a combined patch). -- Adil ---------------------------------------------------------------------- >Comment By: Sadrul H C (sadrul) Date: 2005-06-19 20:02 Message: Logged In: YES user_id=1132702 Hello. 1. updated value.h accordingly 2. I don't think I tampered with any comments. I checked with HEAD, and it does seem the comments are in order. 3. Do I update the Changelog accordingly and submit a patch for that, or will that be done if/when this patch get's accepted by some dev? -- Adil ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-12 10:58 Message: Logged In: YES user_id=156487 As it stood, the plugin didn't even use the buddy icon type stuff yet. I just fixed that. However, for oldstatus, I could do the type stuff in the plugin. To the as-yet-unassigned developer: If it makes it easier, only the signal needs to be backported. Let me know what you'd like to do. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-12 03:53 Message: Logged In: YES user_id=156487 There are a couple things that need changing on this patch: 1. In value.h, this should not be adding a value to the middle of the enum. The end is fine. The reason for this is that it breaks binary compatibility (which is not allowed except for major releases). 2. The comment about GDK should be changed to match what it says in HEAD. This isn't a big deal, but it makes it consistent. 3. This incorporates the buddy icon saving change. (A real extension is set instead of .icon.) This was ChangeLog'ed for 2.0.0. If this backport is to be accepted, that needs to be ChangeLog'ed in oldstatus and removed in HEAD. Be aware that this would force an increase in the minor version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1218914&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 10:40:43
|
Patches item #1222664, was opened at 2005-06-17 14:34 Message generated for change (Comment added) made by gabbath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222664&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabbath (gabbath) Assigned to: Etan Reisner (deryni9) Summary: new signal: buddy-changed-status Initial Comment: i'm really sorry, i couldn't diff against the cvs because i'm probably doing something wrong. i followed the directions for downloading it but from the autogen.sh part it won't work... i'll try again later maybe. anyway, this isn't much, it's a really simple signal, but i find it very useful. also, it can probably be adapted quite easily for the cvs, as it just adds one or two lines of code :)) Changes: src/blist.c -> add "buddy-changed-status" plugins/signals-test.c -> test "buddy-changed-status" Description: the "buddy-changed-status" signal takes place whenever a specified buddy updates his/her status, status text or idle time. i found it very useful for a plugin that i made which shows the buddy's current status and idle time right in the IM window... and it might have other uses too. anyway, "buddy-away" and "buddy-back" aren't enough for this as yahoo (for instance) allows status messages even when you're not away, so instead of refreshing automatically every 30secs, i preferred to add this useful signal (for idle update i suppose one can use "buddy-idle-updated", but i thought it should actually engulf - as its name suggests - all the stuff related to a buddy's status). it's a bit weird that it gets emitted several times when a status changes, not just once, but i suppose it's because when a buddy changes his/her status, it goes from away to back and then away again or something. ---------------------------------------------------------------------- >Comment By: Gabbath (gabbath) Date: 2005-06-19 10:40 Message: Logged In: YES user_id=1298580 bleeter, i have fedora core 3 if it helps in any way. i just follow the exact directions on your site, but they don't work from the autogen.sh part. i've double checked all the packages listed there but it still won't work... any tips? oh, and to be on topic: any comments on the new signal idea? :) ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-06-19 08:10 Message: Logged In: YES user_id=407708 You seem to be having problems pulling from CVS (as indicated with all your patches). Maybe you're not getting the 'oldstatus', and instead the HEAD (which is the very unreliable Gaim2) ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-18 08:49 Message: Logged In: YES user_id=1298580 >It would seem that this patch is basically just for catching >when a buddy switches from one away state to another away >state, yes? well, not exactly, some protocols (like yahoo) can have states without actually being away, like the song they're playing in, say, winamp. and they still appear available. now buddy-away, buddy-back etc don't actually catch these signals as the contact is never really away... none of the signals do. that's why i defined it. oh, and... i have to correct something, it doesn't take place when buddy-idle-updated (my bad, sorry). perhaps i should not have it emit when the buddy goes idle and back... that was just for the sake of completenes, so you can ignore the changes made to gaim_blist_update_buddy_idle ---------------------------------------------------------------------- Comment By: Etan Reisner (deryni9) Date: 2005-06-17 22:30 Message: Logged In: YES user_id=516184 It would seem that this patch is basically just for catching when a buddy switches from one away state to another away state, yes? If that's the case is there a reason you decided to have it duplicate buddy-away, buddy-back, buddy-idle, and buddy-idle-updated rather than just adding a buddy-away-updated? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222664&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 10:29:47
|
Patches item #1222657, was opened at 2005-06-17 14:26 Message generated for change (Comment added) made by gabbath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222657&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabbath (gabbath) Assigned to: Nobody/Anonymous (nobody) Summary: better yahoo buzz Initial Comment: sorry, cvs didn't work, following the directions on your site so i diffed against regular gaim 1.3.1 ...anyway, don't think it actually matters that much, it's not a core thing, just added a few lines here and there (i'm just a beginner) Changes: src/sound.h -> added GAIM_SOUND_BUZZ_YAHOO src/protocols/yahoo/yahoo.c -> made it play buzz sound when "<ding>" message is received (just added a gaim_sound_play_event line) src/gtkprefs.c -> added a small comment about the buzz sound bypassing sound options (just thought the user should know... might have been better to use a tooltip...) - thought it should bypass as it's supposed to get your attention and shouldn't be muted, but you can always uncheck it from the sounds list if you want to src/gtksound.c -> added "Someone buzzes you (Yahoo only)" to sounds in preferences; you can use the default sound or you can use a sound of your choice... it's integrated just like the other sounds, it just bypasses the sound options in prefs sounds/makefile.in and sounds/makefile.am (also added sounds/buzz.wav) -> embeds the buzz sound within gaim and installs it along with the other default sounds plugins/buzz.c -> this is a patch for the buzz plugin by avinash prasad which i consider to be the best for gaim; it can send buzz to someone via Ctrl+G shortcut and also displays "BUZZ!!!" in conversation; i also added a gaim_sound_play_event line to it and so it now plays the sound (specified in prefs) when you buzz someone (not very useful, but still...) you can find the original buzz plugin here: http://www.cse.iitd.ernet.in/~csd00379/buzz.c Description: well what you get from all this mess is that now you can send and receive the buzz if you're on a yahoo account. you can send it with sound via ctrl+g (through the buzz plugin by avinash prasad) or without sound via /buzz (through gaim main). when you receive it you also receive it with sound. the sound is universal, you can either enable or disable it from sound preferences. i included a default sound (sounds/buzz.wav, not the buzz sound from yahoo but rather a higher pitched version of arrive.wav - didn't want to infringe any copyrights) but you can also select another file to play, from your disk, even the doorbell.wav from the yahoo messenger directory. The behaviour is practically identical to yahoo messenger and... well... i guess that's all that matters in the end for a yahoo user switching to gaim :) couldn't help myself from changing "Buzz!!" to a bolded "BUZZ!!!" :) ---------------------------------------------------------------------- >Comment By: Gabbath (gabbath) Date: 2005-06-19 10:29 Message: Logged In: YES user_id=1298580 rlaager: alright, a plugin is ok too. i've no objection to that. maybe a plugin to deal with alert options overall. but first the alerts should be implemented for all protocols that support "buzzing". i'll see what i can do in a few weeks, but right now i've got some exams. bleeter: the job's been done for yahoo, if you want to use anything i've submitted here, feel free to do so. but as a user i want to tell you what i'd like: some message in the IM telling me that i got buzzed, sounds on receive (sounds on send seem a bit useless) and a shortcut key combination like ctrl+g (slash commands take longer to type). and i guess the window manager should flash the conversation's corresponding item in the taskbar :) cheers ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-19 09:53 Message: Logged In: YES user_id=156487 Adding an option for bypassing the settings isn't likely to fly. Many preferences were slashed in CVS to make the configuration easy for users. If you want the sound to play regardless of your other sound settings, you could whip up a very simple plugin to do that. ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-19 09:04 Message: Logged In: YES user_id=1298580 >First off, I don't like this idea of a sound bypassing... Well you can just disable the sound in the first place, but I agree with you that some people might find this unacceptable, and if not then just plain unesthetic. So how about this then: treat it like the other sounds by default, but add a third sound option whether or not to have buzz bypass the sound options. No hurt in that :) >Second, if you're adding a sound, it should be something... I designed it this way because I only use Yahoo. Silly me. Of course this thing should be extended to all protocols that have similar features. I'm just not familiar with the others. But buzz is a first step. Anyway, my overall point was that buzzes/nudges/whatever are first of all alerts, they're meant to notify you that someone wants to talk to you, that there's an emergency or something. So they need to be accompanied by sounds, otherwise they're useless. And if I don't want sounds when I'm away/idle (I don't want to be bothered anytime a buddy signs on or off), I'd most certainly like to know if someone has something urgent to tell me, hence the bypassing idea. Oh, and if they're meant to be universal, they should be called something like buddy alerts. And also a universal key combination for alerting buddies. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-06-19 08:02 Message: Logged In: YES user_id=407708 I'm preparing a generic gaim core buzz, which will replace the current yahoo buzz. Feel free to beat me to finalisation :-) Beyond that, I agree with rlaager's comments. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-19 04:29 Message: Logged In: YES user_id=156487 First off, I don't like this idea of a sound bypassing the muting options. That's totally unacceptable. *I* control which sounds play on my computer, not another user sending me a buzz. Second, if you're adding a sound, it should be something along the lines of GAIM_SOUND_BELL because other protocols have similar features. For example, MSN has nudges. These will need to be treated the same by Gaim. Therefore, you shouldn't make this protocol specific (which is unacceptable for anything in the core, really). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222657&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 10:03:41
|
Patches item #1222650, was opened at 2005-06-17 14:18 Message generated for change (Comment added) made by gabbath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222650&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabbath (gabbath) Assigned to: Nobody/Anonymous (nobody) Summary: small & useful buddylist tweaks (more Yahoo-like) Initial Comment: I diffed against official release 1.3.1 because i couldn't get cvs to work. very sorry, but it's a very small patch for gtkblist.c Changes: src/gtkblist.c -> added ctrl+h toggle for showing offline contacts or not -> changed the status message length to 40 instead of just 20 (ok, 40 may be a little too much, but 30-35 is really okay) -> changed buddy list small icon view to format "buddy - status", with status grayed out and buddy name bolded if online (bold+dim if idle... if checked in prefs of course) - very very similar to yahoo messenger's buddy list Description: uh, i'm too much of a yahoo user to not do this. but i think it's really useful. i've always liked a compact list, without buddy icons. but in small view i couldn't see my buddies' statuses. so i did this. i also made the status text longer because it was a bit short imho... ---------------------------------------------------------------------- >Comment By: Gabbath (gabbath) Date: 2005-06-19 10:03 Message: Logged In: YES user_id=1298580 uh, text got deleted just before i wanted to send: 1. Agreed, I had no preference for CTRL+H, just wanted a shortcut and yahoo messenger suggested that one... so CTRL+O it is :) 2. 40 is a bit long, but 30 is really OK. It's not critical info, but I just found myself hovering over the buddylist and waiting for tooltips to appear so I'm guessing it should be a little longer. Besides, lots of people display the song from winamp in yahoo messenger and with 20 chars you just see the artist :P 3. Agree here too. Didn't really like the bold, but those dim icons are a bit hard to tell apart, so i thought the text should be somewhat different too. In conclusion, here's a new diff for gtkblist, with CTRL+O, 30 chars and no bold (aah, much better). But still, the status showing in both big & small view should be a good idea (actually this was one thing that bugged me with gaim as i liked small view but wanted to also see my friends' statuses) ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-19 10:03 Message: Logged In: YES user_id=1298580 uh, text got deleted just before i wanted to send: 1. Agreed, I had no preference for CTRL+H, just wanted a shortcut and yahoo messenger suggested that one... so CTRL+O it is :) 2. 40 is a bit long, but 30 is really OK. It's not critical info, but I just found myself hovering over the buddylist and waiting for tooltips to appear so I'm guessing it should be a little longer. Besides, lots of people display the song from winamp in yahoo messenger and with 20 chars you just see the artist :P 3. Agree here too. Didn't really like the bold, but those dim icons are a bit hard to tell apart, so i thought the text should be somewhat different too. In conclusion, here's a new diff for gtkblist, with CTRL+O, 30 chars and no bold (aah, much better). But still, the status showing in both big & small view should be a good idea (actually this was one thing that bugged me with gaim as i liked small view but wanted to also see my friends' statuses) ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-06-19 08:08 Message: Logged In: YES user_id=407708 A few comments: 1. CTRL+O is mapped for showing offline buddies in HEAD. I suggest leaving CTRL+H alone, as H would tend to infer (H)elp. It'd be best if you just prepare a backport of the HEAD cvs code, rather than have different code. 2. Why is 20 insufficient? What critical infomation might one miss between chars 20-40? 3. 'Offline' status is indicated by a different protocol icon (in Y!'s case, the Y! happy face with a 'no entry' type indicator over it). As this icon is not used to indicate any form of online buddy, I don't see the need for the additional hacking you've done. ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-18 09:05 Message: Logged In: YES user_id=1298580 i made online buddies bold so that you can tell dimmed idle buddies from offline buddies. if anyone has a better idea for this, feel free to tell me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222650&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 10:03:40
|
Patches item #1222650, was opened at 2005-06-17 14:18 Message generated for change (Comment added) made by gabbath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222650&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabbath (gabbath) Assigned to: Nobody/Anonymous (nobody) Summary: small & useful buddylist tweaks (more Yahoo-like) Initial Comment: I diffed against official release 1.3.1 because i couldn't get cvs to work. very sorry, but it's a very small patch for gtkblist.c Changes: src/gtkblist.c -> added ctrl+h toggle for showing offline contacts or not -> changed the status message length to 40 instead of just 20 (ok, 40 may be a little too much, but 30-35 is really okay) -> changed buddy list small icon view to format "buddy - status", with status grayed out and buddy name bolded if online (bold+dim if idle... if checked in prefs of course) - very very similar to yahoo messenger's buddy list Description: uh, i'm too much of a yahoo user to not do this. but i think it's really useful. i've always liked a compact list, without buddy icons. but in small view i couldn't see my buddies' statuses. so i did this. i also made the status text longer because it was a bit short imho... ---------------------------------------------------------------------- >Comment By: Gabbath (gabbath) Date: 2005-06-19 10:03 Message: Logged In: YES user_id=1298580 uh, text got deleted just before i wanted to send: 1. Agreed, I had no preference for CTRL+H, just wanted a shortcut and yahoo messenger suggested that one... so CTRL+O it is :) 2. 40 is a bit long, but 30 is really OK. It's not critical info, but I just found myself hovering over the buddylist and waiting for tooltips to appear so I'm guessing it should be a little longer. Besides, lots of people display the song from winamp in yahoo messenger and with 20 chars you just see the artist :P 3. Agree here too. Didn't really like the bold, but those dim icons are a bit hard to tell apart, so i thought the text should be somewhat different too. In conclusion, here's a new diff for gtkblist, with CTRL+O, 30 chars and no bold (aah, much better). But still, the status showing in both big & small view should be a good idea (actually this was one thing that bugged me with gaim as i liked small view but wanted to also see my friends' statuses) ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-06-19 08:08 Message: Logged In: YES user_id=407708 A few comments: 1. CTRL+O is mapped for showing offline buddies in HEAD. I suggest leaving CTRL+H alone, as H would tend to infer (H)elp. It'd be best if you just prepare a backport of the HEAD cvs code, rather than have different code. 2. Why is 20 insufficient? What critical infomation might one miss between chars 20-40? 3. 'Offline' status is indicated by a different protocol icon (in Y!'s case, the Y! happy face with a 'no entry' type indicator over it). As this icon is not used to indicate any form of online buddy, I don't see the need for the additional hacking you've done. ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-18 09:05 Message: Logged In: YES user_id=1298580 i made online buddies bold so that you can tell dimmed idle buddies from offline buddies. if anyone has a better idea for this, feel free to tell me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222650&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 09:53:22
|
Patches item #1222657, was opened at 2005-06-17 09:26 Message generated for change (Comment added) made by rlaager You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222657&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabbath (gabbath) Assigned to: Nobody/Anonymous (nobody) Summary: better yahoo buzz Initial Comment: sorry, cvs didn't work, following the directions on your site so i diffed against regular gaim 1.3.1 ...anyway, don't think it actually matters that much, it's not a core thing, just added a few lines here and there (i'm just a beginner) Changes: src/sound.h -> added GAIM_SOUND_BUZZ_YAHOO src/protocols/yahoo/yahoo.c -> made it play buzz sound when "<ding>" message is received (just added a gaim_sound_play_event line) src/gtkprefs.c -> added a small comment about the buzz sound bypassing sound options (just thought the user should know... might have been better to use a tooltip...) - thought it should bypass as it's supposed to get your attention and shouldn't be muted, but you can always uncheck it from the sounds list if you want to src/gtksound.c -> added "Someone buzzes you (Yahoo only)" to sounds in preferences; you can use the default sound or you can use a sound of your choice... it's integrated just like the other sounds, it just bypasses the sound options in prefs sounds/makefile.in and sounds/makefile.am (also added sounds/buzz.wav) -> embeds the buzz sound within gaim and installs it along with the other default sounds plugins/buzz.c -> this is a patch for the buzz plugin by avinash prasad which i consider to be the best for gaim; it can send buzz to someone via Ctrl+G shortcut and also displays "BUZZ!!!" in conversation; i also added a gaim_sound_play_event line to it and so it now plays the sound (specified in prefs) when you buzz someone (not very useful, but still...) you can find the original buzz plugin here: http://www.cse.iitd.ernet.in/~csd00379/buzz.c Description: well what you get from all this mess is that now you can send and receive the buzz if you're on a yahoo account. you can send it with sound via ctrl+g (through the buzz plugin by avinash prasad) or without sound via /buzz (through gaim main). when you receive it you also receive it with sound. the sound is universal, you can either enable or disable it from sound preferences. i included a default sound (sounds/buzz.wav, not the buzz sound from yahoo but rather a higher pitched version of arrive.wav - didn't want to infringe any copyrights) but you can also select another file to play, from your disk, even the doorbell.wav from the yahoo messenger directory. The behaviour is practically identical to yahoo messenger and... well... i guess that's all that matters in the end for a yahoo user switching to gaim :) couldn't help myself from changing "Buzz!!" to a bolded "BUZZ!!!" :) ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-19 04:53 Message: Logged In: YES user_id=156487 Adding an option for bypassing the settings isn't likely to fly. Many preferences were slashed in CVS to make the configuration easy for users. If you want the sound to play regardless of your other sound settings, you could whip up a very simple plugin to do that. ---------------------------------------------------------------------- Comment By: Gabbath (gabbath) Date: 2005-06-19 04:04 Message: Logged In: YES user_id=1298580 >First off, I don't like this idea of a sound bypassing... Well you can just disable the sound in the first place, but I agree with you that some people might find this unacceptable, and if not then just plain unesthetic. So how about this then: treat it like the other sounds by default, but add a third sound option whether or not to have buzz bypass the sound options. No hurt in that :) >Second, if you're adding a sound, it should be something... I designed it this way because I only use Yahoo. Silly me. Of course this thing should be extended to all protocols that have similar features. I'm just not familiar with the others. But buzz is a first step. Anyway, my overall point was that buzzes/nudges/whatever are first of all alerts, they're meant to notify you that someone wants to talk to you, that there's an emergency or something. So they need to be accompanied by sounds, otherwise they're useless. And if I don't want sounds when I'm away/idle (I don't want to be bothered anytime a buddy signs on or off), I'd most certainly like to know if someone has something urgent to tell me, hence the bypassing idea. Oh, and if they're meant to be universal, they should be called something like buddy alerts. And also a universal key combination for alerting buddies. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-06-19 03:02 Message: Logged In: YES user_id=407708 I'm preparing a generic gaim core buzz, which will replace the current yahoo buzz. Feel free to beat me to finalisation :-) Beyond that, I agree with rlaager's comments. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-18 23:29 Message: Logged In: YES user_id=156487 First off, I don't like this idea of a sound bypassing the muting options. That's totally unacceptable. *I* control which sounds play on my computer, not another user sending me a buzz. Second, if you're adding a sound, it should be something along the lines of GAIM_SOUND_BELL because other protocols have similar features. For example, MSN has nudges. These will need to be treated the same by Gaim. Therefore, you shouldn't make this protocol specific (which is unacceptable for anything in the core, really). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222657&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-19 09:23:18
|
Patches item #1223530, was opened at 2005-06-19 04:23 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=1223530&group_id=235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Nobody/Anonymous (nobody) Summary: GtkImHtml Image Save Error Dialogs Initial Comment: When saving an image from a GtkImHtml, a couple different errors can occur. The existing code creates a dialog for these situations, but never shows it. This patch fixes that and also improves the formatting of the dialogs. The moral of the story? Don't think about using code from Gaim in your plugin because you'll just find the Gaim code is broken and then you have to submit a patch. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1223530&group_id=235 |
3 messages has been excluded from this view by a project administrator.
