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-26 01:11:13
|
Patches item #1227590, was opened at 2005-06-25 20:50 Message generated for change (Comment added) made by deryni9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227590&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: Accepted Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Nobody/Anonymous (nobody) Summary: Compile Warning in gtkblist.c Initial Comment: This patch fixes a compiler warning in gtkblist.c. The function itself was removed on Monday as part of Sean's alias/group name editing change. The prototype was missed. I'm slacking, this warning lasted almost a week. ;-) ---------------------------------------------------------------------- >Comment By: Etan Reisner (deryni9) Date: 2005-06-25 21:11 Message: Logged In: YES user_id=516184 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227590&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-26 00:50:58
|
Patches item #1227590, was opened at 2005-06-25 19: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=1227590&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: Compile Warning in gtkblist.c Initial Comment: This patch fixes a compiler warning in gtkblist.c. The function itself was removed on Monday as part of Sean's alias/group name editing change. The prototype was missed. I'm slacking, this warning lasted almost a week. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227590&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-26 00:39:10
|
Patches item #1226022, was opened at 2005-06-23 00:06 Message generated for change (Comment added) made by rlaager You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&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: Reload modified plugins at runtime Initial Comment: Hello. When gaim is running, an updated .so-plugin is not reloaded (I am told script-plugins are reloaded though). So if anyone has re-installed a `native-plugin', he has to restart gaim to get that modified plugin to work. This patch allows a plugin to be reloaded at runtime. However, it reloads only when the plugin is not being used (ie, not loaded) and about to be used (ie, the user has checked the box at the preference-dialog) to make sure things don't go crazy. It makes life easier especially for people who create plugins. And makes thing somewhat consistent in the sense that plugins written in any language can be reloaded at runtime. This patch is against oldstatus. I took a look at HEAD, and I think little modifications will allow for this patch to go with HEAD as well. So if this way of doing things is OK, then I can create a patch against HEAD. -- Adil ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-25 19:39 Message: Logged In: YES user_id=156487 I've got a confirmed crash with this patch. Steps to reproduce: 1. Apply this patch, build Gaim, install. 2. Start Gaim without gevolution enabled. 3. Apply patch 1218079 to gevolution. 4. From plugins/evolution, run make install. 5. Try to enable "Evolution Integration" from Gaim. 6. Crash! I suspect this would happen with any patch that changed gevolution. Without this patch, you'd obviously get the old copy of gevolution, but there's no crash. The patch I used as an example (1218079) works for me (as documented there), so I don't think there's anything wrong with that patch in particular. ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-24 00:10 Message: Logged In: YES user_id=1132702 Replaced _reload() with my version of it. This shouldn't break anything because it was never used anyway. Made patch against HEAD. Added lines in Changelog and plugins/ChangeLog.API. I am testing the patch with my plugins. It would be great if some prpl-people would check it as well. (Bleeter said he would test it in the next few days). -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 20:00 Message: Logged In: YES user_id=20979 That should have been "the patch should be against head." ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 16:11 Message: Logged In: YES user_id=20979 "rename the hard_reload() to _reload()" I have no idea, I haven't looked at the code. Maybe they'll need to be merged? You should do whatever is needed to make the plugin API cleaner, and allow for plugins to be reloaded on the fly. I also don't know the issues Paco-Paco had, but it's probably a good idea to test this A LOT. Yes, the patch should be against add. Adding a line to plugins/ChangeLog.API is probably a good idea. Adding a line to the normal ChangeLog is also not a bad idea. And it may be better to provide one patch for both types of plugins (since they should be pretty similar...) ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 15:28 Message: Logged In: YES user_id=1132702 Do you suggest I just remove the existing _reload() and rename the hard_reload() to _reload() ? Should I also get a patch for HEAD, and add a line in plugins/ChangeLog.API? I took a close look (as per my standards) at _plugin_destroy() and didn't notice anything that might go wrong. But I am probably not the best person to say anything on this, and I don't know the details of the probs/issues Paco-Paco had had with it. Note: Now that I have had a closer look, it seems loader-plugins will need to be reloaded somewhere. (one of the patches deal with regular plugins, the other with protocol-plugins). -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 10:51 Message: Logged In: YES user_id=20979 If gaim_plugin_reload() is never used then I get the feeling its original intention was to do what you're trying to do, and it would be better to change/replace it with your version. ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 08:00 Message: Logged In: YES user_id=1132702 I have now used g_stat (and updated the patch). grep tells me gaim_plugin_reload() is never called from anywhere (unless some plugin uses it). So changing/replacing it probably won't have any side-effects. -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 07:38 Message: Logged In: YES user_id=20979 Definitely no configure flag (why would you ever want to disable this?) Is it possible to use g_stat or g_file_get_timestamp or something and avoid the use of stat? Could the plugin API reload a plugin automatically if it has changed, instead of making the preferences API deal with it? When is gaim_plugin_reload() used? Could it be changed to always do the "hard" reload? What side-effects would this have? ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 06:45 Message: Logged In: YES user_id=1132702 I added the stuff to work with prpl-s. Added the stuff in gaim_find_prpl (prpl.c) which seemed the most appropriate place to do it. I did a very simple check whether this works or not (changed a few strings in msn/session.c :-) ), and it seemed to work OK. But it'd be great if someone else checked these out and let me know the results. -- Adil ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 03:55 Message: Logged In: YES user_id=1132702 Perhaps I should reload only the modified *native* plugins? I am looking at prpl-s now. And it seems reloading the modified protocol-plugin can be done at gaim_connection_connect (connection.c) (it will of course, need to be made sure that no other account using that prpl is active) Perhaps this feature can/should be added with some configure-flags so that only the concerned people (the developers) have anything to do with it? -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-25 23:54:19
|
Patches item #1218079, was opened at 2005-06-10 05:06 Message generated for change (Comment added) made by rlaager You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1218079&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: Stanislav Brabec (sbrabec) Assigned to: Nobody/Anonymous (nobody) Summary: Groupwise evolution integration patch Initial Comment: Attached patch adds basic support for Novell Groupwise to Gaim Evolution integration. New Person dialog for both Add Buddy and Evolution Integration can be improved in future to be able to get name, e-mail and maybe other information from Groupwise. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-25 18:54 Message: Logged In: YES user_id=156487 This looks right to me. It compiles and loads. I don't have a Novell Groupwise server, so I couldn't test the actual functionality, but it doesn't seem to break anything. ---------------------------------------------------------------------- Comment By: Stanislav Brabec (sbrabec) Date: 2005-06-10 07:17 Message: Logged In: YES user_id=616997 The patch only adds Groupwise to known protocols to gevolution plugin. It does not fill name and e-mail while adding buddy to addressbook. Groupwise explicitly provides this information (see nmuserrecord.c). For other protocols it can be done, too, but with some limitations. ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2005-06-10 06:21 Message: Logged In: YES user_id=28833 how does this differ from the gevolution plugin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1218079&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-25 23:44:55
|
Patches item #1218914, was opened at 2005-06-11 16:04 Message generated for change (Comment added) made by rlaager 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: Richard Laager (rlaager) Date: 2005-06-25 18:44 Message: Logged In: YES user_id=156487 I've taken this patch and cleaned it up. It should be in a directly committable state as 1227578. ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-19 09: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-11 23: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-11 16: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-25 23:43:19
|
Patches item #1227578, was opened at 2005-06-25 18:43 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=1227578&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 Icon Backport Initial Comment: This is a completed backport of two of my buddy icon patches. This patch supercedes sadrul's partial backport (1218914). See my latest comment in 1224610... This should be accepted for the same release (hopefully 1.4.0) as 1224610. However, it's important that 1224610 be accepted first. This patch is designed to apply cleanly after that patch has been applied. Make sure to cvs add doc/buddyicon-signals.dox after applying this patch. Also included is a simple patch to HEAD to remove these items from the ChangeLogs since they'll make their first appearance in a release < 2.0.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227578&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-25 21:58:06
|
Patches item #1224610, was opened at 2005-06-21 00:49 Message generated for change (Comment added) made by rlaager 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. ---------------------------------------------------------------------- >Comment By: Richard Laager (rlaager) Date: 2005-06-25 16:58 Message: Logged In: YES user_id=156487 Here are patches for HEAD and oldstatus. The patch for oldstatus increases the minor version number. Mark, We had talked about how I was going to clean up sadrul's backport of two of my patches. You said you'd accept them as long as they didn't break anything in oldstatus. This would increase the minor version of oldstatus anyway, so that's why this patch to oldstatus adds a new function. I'll clean up the backport patch later today. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-22 18:08 Message: Logged In: YES user_id=156487 I thought about adding a function to buddylist.c to delete the icon file. With the current architecture, that spot in blist.c is the only non-buddyicon.c code to delete a buddy icon cache file. I wasn't sure that it justified adding another public function. Also, there's the issue of increasing the minor version on oldstatus. It sounds like you'd have no objections to a new function in buddylist.c, so I'll rework the patch to add one. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-22 17:27 Message: Logged In: YES user_id=20979 It looks like gaim_buddy_icon_cache() in src/buddylist.c is responsible for writing the buddy icon file? Would it make more sense if blist.c called a buddylist.c function to delete the icon file? ---------------------------------------------------------------------- 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-25 07:57:18
|
Patches item #1227281, was opened at 2005-06-25 03:42 Message generated for change (Comment added) made by sadrul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227281&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: Filtering in the Debug Window Initial Comment: Hello. It'd be very helpful if the text in the debug-window could be filtered. This patch adds the most simplistic filtering for the incoming debug-messages (brining in regular expressions may be an option, but that would probably be overkill). -- Adil ---------------------------------------------------------------------- >Comment By: Sadrul H C (sadrul) Date: 2005-06-25 13:57 Message: Logged In: YES user_id=1132702 I have mode some changes, updated screenshots here: http://adil.dotgeek.org/gaim/debug_filter.png http://adil.dotgeek.org/gaim/debug_filter2.png But deryni is working on a filter-thing as well, which, by the sound of it, will probably be a better one. (it won't be the first time I've done something already done/being done in a better fashion :| ) -- Adil ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-25 08:30 Message: Logged In: YES user_id=1132702 Here's how the debug window looks like after the patch: http://adil.dotgeek.org/gaim/log_filter.png -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227281&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-25 02:30:29
|
Patches item #1227281, was opened at 2005-06-25 03:42 Message generated for change (Comment added) made by sadrul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227281&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: Filtering in the Debug Window Initial Comment: Hello. It'd be very helpful if the text in the debug-window could be filtered. This patch adds the most simplistic filtering for the incoming debug-messages (brining in regular expressions may be an option, but that would probably be overkill). -- Adil ---------------------------------------------------------------------- >Comment By: Sadrul H C (sadrul) Date: 2005-06-25 08:30 Message: Logged In: YES user_id=1132702 Here's how the debug window looks like after the patch: http://adil.dotgeek.org/gaim/log_filter.png -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227281&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 21:42:25
|
Patches item #1227281, was opened at 2005-06-25 03:42 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=1227281&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: Filtering in the Debug Window Initial Comment: Hello. It'd be very helpful if the text in the debug-window could be filtered. This patch adds the most simplistic filtering for the incoming debug-messages (brining in regular expressions may be an option, but that would probably be overkill). -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227281&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 20:02:21
|
Patches item #1227231, was opened at 2005-06-25 02:02 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=1227231&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: [HEAD] New signal account-status-changed Initial Comment: Hello. There's currently a signal `account-away' which is never emit-ed in HEAD. This patch introduces a new signal `account-status-changed' which is emitted when (right after) the status of an account gets changed. (`account-away' can be removed if this signal is provided) I have added codes to test the signal in `plugins/signals-test.c' and documented in `doc/account-signals.dox' -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227231&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 18:07:19
|
Patches item #1226701, was opened at 2005-06-23 20:43 Message generated for change (Comment added) made by datallah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226701&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: Duarte Henriques (maxcow) Assigned to: Nobody/Anonymous (nobody) Summary: API addition: get_prpl_icon_uri Initial Comment: I made a plugin for old_status (don't know about HEAD) and needed to get the filename of a prpl icon. Gaim has this: gtkblist.c::gaim_gtk_create_prpl_icon() which returns a GdkPixbuf and is obviously GTK+ specific. So, I think that a function like this should be added: static gchar *get_prpl_icon_uri(GaimAccount *account); perhaps in prpl.h, and gaim_gtk_create_prpl_icon be made to use that. possible implementation attached. ---------------------------------------------------------------------- >Comment By: Daniel Atallah (datallah) Date: 2005-06-24 13:07 Message: Logged In: YES user_id=325843 Moved to patch tracker. Ideally, what needs to happen is to create a pixmap search path, (or possibly alternatively, relative to where plugins are installed to), then you can just search for the image name and retrieve the most appropriate match. This actually isn't even necessary per se, since you can effectively determine the information from inside your plugin (guifications does this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226701&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 18:05:27
|
Patches item #1227165, was opened at 2005-06-25 00:00 Message generated for change (Comment added) made by sadrul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227165&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: Load new plugins at runtime Initial Comment: Hello. It would be great if gaim could add new plugins in the least that were added while gaim was running. It is a one-liner, it calls gaim_plugin_probe, which is called at start-up from the core just once. This patch makes the call when the preferences-page is being loaded (since that's the only way a user can enable the new plugin anyway), and gaim_plugin_probe does nothing about the plugins that were already loaded earlier. [This patch is in no way connected to "[1226022] Reload modified plugins at runtime" :) ] -- Adil ---------------------------------------------------------------------- >Comment By: Sadrul H C (sadrul) Date: 2005-06-25 00:05 Message: Logged In: YES user_id=1132702 >> It would be great if gaim could add new plugins in >> the least that were added while gaim was running. It would be great if gaim could add new plugins in the *list* that were added while gaim was running. -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227165&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 18:00:57
|
Patches item #1227165, was opened at 2005-06-25 00:00 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=1227165&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: Load new plugins at runtime Initial Comment: Hello. It would be great if gaim could add new plugins in the least that were added while gaim was running. It is a one-liner, it calls gaim_plugin_probe, which is called at start-up from the core just once. This patch makes the call when the preferences-page is being loaded (since that's the only way a user can enable the new plugin anyway), and gaim_plugin_probe does nothing about the plugins that were already loaded earlier. [This patch is in no way connected to "[1226022] Reload modified plugins at runtime" :) ] -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1227165&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 15:54:28
|
Patches item #1224555, was opened at 2005-06-20 20:50 Message generated for change (Comment added) made by datallah 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. ---------------------------------------------------------------------- >Comment By: Daniel Atallah (datallah) Date: 2005-06-24 10:54 Message: Logged In: YES user_id=325843 I'm guessing that this is related to the whole GTK+ focus problem: http://bugzilla.gnome.org/show_bug.cgi?id=107320 This seems like it isn't a bad workaround to this annoyance (it probably should be #ifdef _WIN32 'd) until this gtk bug is sorted (which, as you can see in the bug report, isn't particlarly likely to happen soon). This also could probably be done to prevent the popup from interfering with dnd of blist nodes. ---------------------------------------------------------------------- Comment By: Enix (enix) Date: 2005-06-22 18:12 Message: Logged In: YES user_id=17877 i just attached a screenshot of the problem on windows XP ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-22 17:35 Message: Logged In: YES user_id=20979 I can't reproduce the problem you're describing. Do you only have this problem when using MS Windows? Could you take a screen shot? I'm not opposed to fixing this, but it sounds like it might be something we'll want to file a gtk bug about (I'm thinking that when the context menu is open then the blist should not have focus, and should therefore not display the tooltip). ---------------------------------------------------------------------- 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-24 05:10:34
|
Patches item #1226022, was opened at 2005-06-23 11:06 Message generated for change (Comment added) made by sadrul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&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: Reload modified plugins at runtime Initial Comment: Hello. When gaim is running, an updated .so-plugin is not reloaded (I am told script-plugins are reloaded though). So if anyone has re-installed a `native-plugin', he has to restart gaim to get that modified plugin to work. This patch allows a plugin to be reloaded at runtime. However, it reloads only when the plugin is not being used (ie, not loaded) and about to be used (ie, the user has checked the box at the preference-dialog) to make sure things don't go crazy. It makes life easier especially for people who create plugins. And makes thing somewhat consistent in the sense that plugins written in any language can be reloaded at runtime. This patch is against oldstatus. I took a look at HEAD, and I think little modifications will allow for this patch to go with HEAD as well. So if this way of doing things is OK, then I can create a patch against HEAD. -- Adil ---------------------------------------------------------------------- >Comment By: Sadrul H C (sadrul) Date: 2005-06-24 11:10 Message: Logged In: YES user_id=1132702 Replaced _reload() with my version of it. This shouldn't break anything because it was never used anyway. Made patch against HEAD. Added lines in Changelog and plugins/ChangeLog.API. I am testing the patch with my plugins. It would be great if some prpl-people would check it as well. (Bleeter said he would test it in the next few days). -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-24 07:00 Message: Logged In: YES user_id=20979 That should have been "the patch should be against head." ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-24 03:11 Message: Logged In: YES user_id=20979 "rename the hard_reload() to _reload()" I have no idea, I haven't looked at the code. Maybe they'll need to be merged? You should do whatever is needed to make the plugin API cleaner, and allow for plugins to be reloaded on the fly. I also don't know the issues Paco-Paco had, but it's probably a good idea to test this A LOT. Yes, the patch should be against add. Adding a line to plugins/ChangeLog.API is probably a good idea. Adding a line to the normal ChangeLog is also not a bad idea. And it may be better to provide one patch for both types of plugins (since they should be pretty similar...) ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-24 02:28 Message: Logged In: YES user_id=1132702 Do you suggest I just remove the existing _reload() and rename the hard_reload() to _reload() ? Should I also get a patch for HEAD, and add a line in plugins/ChangeLog.API? I took a close look (as per my standards) at _plugin_destroy() and didn't notice anything that might go wrong. But I am probably not the best person to say anything on this, and I don't know the details of the probs/issues Paco-Paco had had with it. Note: Now that I have had a closer look, it seems loader-plugins will need to be reloaded somewhere. (one of the patches deal with regular plugins, the other with protocol-plugins). -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 21:51 Message: Logged In: YES user_id=20979 If gaim_plugin_reload() is never used then I get the feeling its original intention was to do what you're trying to do, and it would be better to change/replace it with your version. ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 19:00 Message: Logged In: YES user_id=1132702 I have now used g_stat (and updated the patch). grep tells me gaim_plugin_reload() is never called from anywhere (unless some plugin uses it). So changing/replacing it probably won't have any side-effects. -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 18:38 Message: Logged In: YES user_id=20979 Definitely no configure flag (why would you ever want to disable this?) Is it possible to use g_stat or g_file_get_timestamp or something and avoid the use of stat? Could the plugin API reload a plugin automatically if it has changed, instead of making the preferences API deal with it? When is gaim_plugin_reload() used? Could it be changed to always do the "hard" reload? What side-effects would this have? ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 17:45 Message: Logged In: YES user_id=1132702 I added the stuff to work with prpl-s. Added the stuff in gaim_find_prpl (prpl.c) which seemed the most appropriate place to do it. I did a very simple check whether this works or not (changed a few strings in msn/session.c :-) ), and it seemed to work OK. But it'd be great if someone else checked these out and let me know the results. -- Adil ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 14:55 Message: Logged In: YES user_id=1132702 Perhaps I should reload only the modified *native* plugins? I am looking at prpl-s now. And it seems reloading the modified protocol-plugin can be done at gaim_connection_connect (connection.c) (it will of course, need to be made sure that no other account using that prpl is active) Perhaps this feature can/should be added with some configure-flags so that only the concerned people (the developers) have anything to do with it? -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 03:52:19
|
Patches item #896804, was opened at 2004-02-13 17:38 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=896804&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: Postponed Priority: 5 Submitted By: Jonas Birmé (birme) Assigned to: Ethan Blanton (eblanton) Summary: DIRCProxy support Initial Comment: Added some support for anyone connected to a Detachable IRC Proxy (www.dircproxy.net). For example, it now detaches from the proxy when the chat-window is closed. And /dircproxy commands can be sent without using the /quote command. Added a config option for the IRC protocol to specify whether the IRC server connected to is a DIRC proxy. This was of quite personal interest, but I thought maybe someone else was interested too. /Jonas ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-06-23 23:52 Message: Logged In: YES user_id=20979 Does this still apply? Can you explain what this does in more detail? I think the /direcproxy command would be better added as a plugin or maybe a perl or tcl script (if that's even possible). I don't see why the account option is necessary. I'll close this for now, please re-open this if it applies against current CVS (head or oldstatus) and you can help me understand what it does. Thanks ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-22 19:20 Message: Logged In: YES user_id=156487 Is this something that could be implemented as a plugin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=896804&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-24 01:00:11
|
Patches item #1226022, was opened at 2005-06-23 01:06 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&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: Reload modified plugins at runtime Initial Comment: Hello. When gaim is running, an updated .so-plugin is not reloaded (I am told script-plugins are reloaded though). So if anyone has re-installed a `native-plugin', he has to restart gaim to get that modified plugin to work. This patch allows a plugin to be reloaded at runtime. However, it reloads only when the plugin is not being used (ie, not loaded) and about to be used (ie, the user has checked the box at the preference-dialog) to make sure things don't go crazy. It makes life easier especially for people who create plugins. And makes thing somewhat consistent in the sense that plugins written in any language can be reloaded at runtime. This patch is against oldstatus. I took a look at HEAD, and I think little modifications will allow for this patch to go with HEAD as well. So if this way of doing things is OK, then I can create a patch against HEAD. -- Adil ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-06-23 21:00 Message: Logged In: YES user_id=20979 That should have been "the patch should be against head." ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 17:11 Message: Logged In: YES user_id=20979 "rename the hard_reload() to _reload()" I have no idea, I haven't looked at the code. Maybe they'll need to be merged? You should do whatever is needed to make the plugin API cleaner, and allow for plugins to be reloaded on the fly. I also don't know the issues Paco-Paco had, but it's probably a good idea to test this A LOT. Yes, the patch should be against add. Adding a line to plugins/ChangeLog.API is probably a good idea. Adding a line to the normal ChangeLog is also not a bad idea. And it may be better to provide one patch for both types of plugins (since they should be pretty similar...) ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 16:28 Message: Logged In: YES user_id=1132702 Do you suggest I just remove the existing _reload() and rename the hard_reload() to _reload() ? Should I also get a patch for HEAD, and add a line in plugins/ChangeLog.API? I took a close look (as per my standards) at _plugin_destroy() and didn't notice anything that might go wrong. But I am probably not the best person to say anything on this, and I don't know the details of the probs/issues Paco-Paco had had with it. Note: Now that I have had a closer look, it seems loader-plugins will need to be reloaded somewhere. (one of the patches deal with regular plugins, the other with protocol-plugins). -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 11:51 Message: Logged In: YES user_id=20979 If gaim_plugin_reload() is never used then I get the feeling its original intention was to do what you're trying to do, and it would be better to change/replace it with your version. ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 09:00 Message: Logged In: YES user_id=1132702 I have now used g_stat (and updated the patch). grep tells me gaim_plugin_reload() is never called from anywhere (unless some plugin uses it). So changing/replacing it probably won't have any side-effects. -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 08:38 Message: Logged In: YES user_id=20979 Definitely no configure flag (why would you ever want to disable this?) Is it possible to use g_stat or g_file_get_timestamp or something and avoid the use of stat? Could the plugin API reload a plugin automatically if it has changed, instead of making the preferences API deal with it? When is gaim_plugin_reload() used? Could it be changed to always do the "hard" reload? What side-effects would this have? ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 07:45 Message: Logged In: YES user_id=1132702 I added the stuff to work with prpl-s. Added the stuff in gaim_find_prpl (prpl.c) which seemed the most appropriate place to do it. I did a very simple check whether this works or not (changed a few strings in msn/session.c :-) ), and it seemed to work OK. But it'd be great if someone else checked these out and let me know the results. -- Adil ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 04:55 Message: Logged In: YES user_id=1132702 Perhaps I should reload only the modified *native* plugins? I am looking at prpl-s now. And it seems reloading the modified protocol-plugin can be done at gaim_connection_connect (connection.c) (it will of course, need to be made sure that no other account using that prpl is active) Perhaps this feature can/should be added with some configure-flags so that only the concerned people (the developers) have anything to do with it? -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-23 21:11:05
|
Patches item #1226022, was opened at 2005-06-23 01:06 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&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: Reload modified plugins at runtime Initial Comment: Hello. When gaim is running, an updated .so-plugin is not reloaded (I am told script-plugins are reloaded though). So if anyone has re-installed a `native-plugin', he has to restart gaim to get that modified plugin to work. This patch allows a plugin to be reloaded at runtime. However, it reloads only when the plugin is not being used (ie, not loaded) and about to be used (ie, the user has checked the box at the preference-dialog) to make sure things don't go crazy. It makes life easier especially for people who create plugins. And makes thing somewhat consistent in the sense that plugins written in any language can be reloaded at runtime. This patch is against oldstatus. I took a look at HEAD, and I think little modifications will allow for this patch to go with HEAD as well. So if this way of doing things is OK, then I can create a patch against HEAD. -- Adil ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-06-23 17:11 Message: Logged In: YES user_id=20979 "rename the hard_reload() to _reload()" I have no idea, I haven't looked at the code. Maybe they'll need to be merged? You should do whatever is needed to make the plugin API cleaner, and allow for plugins to be reloaded on the fly. I also don't know the issues Paco-Paco had, but it's probably a good idea to test this A LOT. Yes, the patch should be against add. Adding a line to plugins/ChangeLog.API is probably a good idea. Adding a line to the normal ChangeLog is also not a bad idea. And it may be better to provide one patch for both types of plugins (since they should be pretty similar...) ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 16:28 Message: Logged In: YES user_id=1132702 Do you suggest I just remove the existing _reload() and rename the hard_reload() to _reload() ? Should I also get a patch for HEAD, and add a line in plugins/ChangeLog.API? I took a close look (as per my standards) at _plugin_destroy() and didn't notice anything that might go wrong. But I am probably not the best person to say anything on this, and I don't know the details of the probs/issues Paco-Paco had had with it. Note: Now that I have had a closer look, it seems loader-plugins will need to be reloaded somewhere. (one of the patches deal with regular plugins, the other with protocol-plugins). -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 11:51 Message: Logged In: YES user_id=20979 If gaim_plugin_reload() is never used then I get the feeling its original intention was to do what you're trying to do, and it would be better to change/replace it with your version. ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 09:00 Message: Logged In: YES user_id=1132702 I have now used g_stat (and updated the patch). grep tells me gaim_plugin_reload() is never called from anywhere (unless some plugin uses it). So changing/replacing it probably won't have any side-effects. -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 08:38 Message: Logged In: YES user_id=20979 Definitely no configure flag (why would you ever want to disable this?) Is it possible to use g_stat or g_file_get_timestamp or something and avoid the use of stat? Could the plugin API reload a plugin automatically if it has changed, instead of making the preferences API deal with it? When is gaim_plugin_reload() used? Could it be changed to always do the "hard" reload? What side-effects would this have? ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 07:45 Message: Logged In: YES user_id=1132702 I added the stuff to work with prpl-s. Added the stuff in gaim_find_prpl (prpl.c) which seemed the most appropriate place to do it. I did a very simple check whether this works or not (changed a few strings in msn/session.c :-) ), and it seemed to work OK. But it'd be great if someone else checked these out and let me know the results. -- Adil ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 04:55 Message: Logged In: YES user_id=1132702 Perhaps I should reload only the modified *native* plugins? I am looking at prpl-s now. And it seems reloading the modified protocol-plugin can be done at gaim_connection_connect (connection.c) (it will of course, need to be made sure that no other account using that prpl is active) Perhaps this feature can/should be added with some configure-flags so that only the concerned people (the developers) have anything to do with it? -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-23 20:28:33
|
Patches item #1226022, was opened at 2005-06-23 11:06 Message generated for change (Comment added) made by sadrul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&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: Reload modified plugins at runtime Initial Comment: Hello. When gaim is running, an updated .so-plugin is not reloaded (I am told script-plugins are reloaded though). So if anyone has re-installed a `native-plugin', he has to restart gaim to get that modified plugin to work. This patch allows a plugin to be reloaded at runtime. However, it reloads only when the plugin is not being used (ie, not loaded) and about to be used (ie, the user has checked the box at the preference-dialog) to make sure things don't go crazy. It makes life easier especially for people who create plugins. And makes thing somewhat consistent in the sense that plugins written in any language can be reloaded at runtime. This patch is against oldstatus. I took a look at HEAD, and I think little modifications will allow for this patch to go with HEAD as well. So if this way of doing things is OK, then I can create a patch against HEAD. -- Adil ---------------------------------------------------------------------- >Comment By: Sadrul H C (sadrul) Date: 2005-06-24 02:28 Message: Logged In: YES user_id=1132702 Do you suggest I just remove the existing _reload() and rename the hard_reload() to _reload() ? Should I also get a patch for HEAD, and add a line in plugins/ChangeLog.API? I took a close look (as per my standards) at _plugin_destroy() and didn't notice anything that might go wrong. But I am probably not the best person to say anything on this, and I don't know the details of the probs/issues Paco-Paco had had with it. Note: Now that I have had a closer look, it seems loader-plugins will need to be reloaded somewhere. (one of the patches deal with regular plugins, the other with protocol-plugins). -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 21:51 Message: Logged In: YES user_id=20979 If gaim_plugin_reload() is never used then I get the feeling its original intention was to do what you're trying to do, and it would be better to change/replace it with your version. ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 19:00 Message: Logged In: YES user_id=1132702 I have now used g_stat (and updated the patch). grep tells me gaim_plugin_reload() is never called from anywhere (unless some plugin uses it). So changing/replacing it probably won't have any side-effects. -- Adil ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 18:38 Message: Logged In: YES user_id=20979 Definitely no configure flag (why would you ever want to disable this?) Is it possible to use g_stat or g_file_get_timestamp or something and avoid the use of stat? Could the plugin API reload a plugin automatically if it has changed, instead of making the preferences API deal with it? When is gaim_plugin_reload() used? Could it be changed to always do the "hard" reload? What side-effects would this have? ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 17:45 Message: Logged In: YES user_id=1132702 I added the stuff to work with prpl-s. Added the stuff in gaim_find_prpl (prpl.c) which seemed the most appropriate place to do it. I did a very simple check whether this works or not (changed a few strings in msn/session.c :-) ), and it seemed to work OK. But it'd be great if someone else checked these out and let me know the results. -- Adil ---------------------------------------------------------------------- Comment By: Sadrul H C (sadrul) Date: 2005-06-23 14:55 Message: Logged In: YES user_id=1132702 Perhaps I should reload only the modified *native* plugins? I am looking at prpl-s now. And it seems reloading the modified protocol-plugin can be done at gaim_connection_connect (connection.c) (it will of course, need to be made sure that no other account using that prpl is active) Perhaps this feature can/should be added with some configure-flags so that only the concerned people (the developers) have anything to do with it? -- Adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226022&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-23 19:24:16
|
Patches item #1226486, was opened at 2005-06-23 15:23 Message generated for change (Comment added) made by tak_tak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226486&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: Fixes #1224178 Initial Comment: Fixes #1224178. Only tested with IRC. ---------------------------------------------------------------------- >Comment By: Levi Bard (tak_tak) Date: 2005-06-23 15:24 Message: Logged In: YES user_id=644705 (Also applies to oldstatus.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226486&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-23 19:23:13
|
Patches item #1226486, was opened at 2005-06-23 15: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=1226486&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: Fixes #1224178 Initial Comment: Fixes #1224178. Only tested with IRC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1226486&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-23 17:54:19
|
Patches item #1180490, was opened at 2005-04-11 01:10 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1180490&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: Accepted Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Mark Doliner (thekingant) Summary: Autocomplete Screennames in Dialogs Based on Logs Initial Comment: Here it is, the much anticipated (or not) patch to autocomplete screennames based on the logs on the disk. Additionally... 1. It fixes the bug where the View User Log box only had screennames for accounts which are currently online. It lists all accounts, so it should have all screennames as possible completions. 2. It fixes the name of the View User Log box to be "View User Log" instead of "Get User Log". This was done so it matched the menu item. 3. It brings the gaim_log_logger_new function in sync with the GaimLogLogger struct. 4. Some other minor documentation fixes. 5. A ChangeLog.API entry for the removal (by Nathan) of the gaim_find_conversation function. The only reason this is included is that no matter how I submitted the separate patches, you'd end up with separate conflicts because this patch has to add a ChangeLog.API line. This really shouldn't be a big deal, but I'm mentioning it for completeness. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-06-23 13:54 Message: Logged In: YES user_id=20979 Oh, ok. That's cool. It seemed like it wasn't doing that when I was testing, but I just checked and it's working magnifique! Thanks ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-23 12:08 Message: Logged In: YES user_id=156487 Yes. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 08:33 Message: Logged In: YES user_id=20979 Say I have the screen name "IStealCellPhones" in my buddy list, and I set their alias to "BlahBlah." If I type "bla" in the New Instant Message window, does it suggest "BlahBlah"? ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-23 01:50 Message: Logged In: YES user_id=156487 What do you mean "show matching aliases"? ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-22 23:05 Message: Logged In: YES user_id=20979 deryni pointed out that the assertions were there before your patch, sorry about that. This looks good so I applied it. Would it be hard to also show matching aliases in the autocomplete? ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-22 21:41 Message: Logged In: YES user_id=20979 When testing this, I see a bajillion "GLib: g_str_has_prefix: assertion `str != NULL' failed" messages printed to the console when typing letters into the "New Instant Message" request dialog. I started Gaim with "gaim -d," I'm not sure if that'll make a difference. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-06-04 15:31 Message: Logged In: YES user_id=156487 Posting a new version of this patch. It will now apply cleanly against HEAD. It's exactly the same as what Sean reviewed, except: 1. I added another entry to the ChangeLog.API file to mark the additions this patch makes. The previous version of the patch only marked the changed function and not the additions. 2. I added an entry to the ChangeLog file for this feature addition. I hope I'm not being too presumptuous in adding this entry to the patch. ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-04 14:32 Message: Logged In: YES user_id=199625 Mark: This looks pretty good to me, but I can't commit anything right now. Could you handle this patch when you get the chance? ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-04-18 00:05 Message: Logged In: YES user_id=156487 Here's a new version of the patch that takes into account the common logger changes from 1180568. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-04-11 11:55 Message: Logged In: YES user_id=156487 If 1180568 is accepted, I'll need to make a couple changes to this patch. If they're both going to be accepted, either accept that one first and ask me to change this one or accept both and I'll submit another small patch to make the required changes. ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2005-04-11 10:55 Message: Logged In: YES user_id=28833 Sean, Apparently, you asked for this, I'm not sure what I think of the change. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-04-11 01:35 Message: Logged In: YES user_id=156487 6. This patch sorts the completions by screenname. They were previously unsorted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1180490&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-06-23 17:11:35
|
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: Closed Resolution: Rejected Priority: 5 Submitted By: Levi Bard (tak_tak) Assigned to: Ethan Blanton (eblanton) Summary: Global pref for 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-23 13:11 Message: Logged In: YES user_id=644705 30s is the hardcoded default right now for all keepalives - that's why I left it that way in the patch and in the screenshot. If you'll notice from connection.c, the line I changed was: gc->keepalive = gaim_timeout_add(30000, send_keepalive, gc); That's a 30s timeout. If that's too short, then you could look at this patch as also allowing you to set the timeout up to 60min to reduce network traffic. ---------------------------------------------------------------------- Comment By: Ethan Blanton (eblanton) Date: 2005-06-23 12:11 Message: Logged In: YES user_id=298616 I am inclined to agree. I think that IRC should support the keepalive (embodied in another patch), but honestly one should never need a keepalive shorter than many *minutes*; there is only so much network brokenness an IM client can fix. Ethan ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 11:50 Message: Logged In: YES user_id=20979 I think timing out connections within 30 seconds constitutes a broken network, and I don't think the addition of this preference is really justified. If you want opinions from more people, feel free to raise the issue on gaim-devel. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-23 11:38 Message: Logged In: YES user_id=644705 OK, this run is as a global network pref, and uses gc->keepalive. On a decent network, the default *should* be fine, but there are some networks bad enough where this is not the case. Screenshot at http://bard.sytes.net/global_ping_again.jpg ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-22 13:40 Message: Logged In: YES user_id=199625 I don't actually mean to make it a preference, but if you *did*, it would be a single option in Network, not multiple options for each protocol. Regardless, there is no NAT device that can't keep a connection open for at least a minute. Leaving it unconfigurable should be fine. -s. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-22 13:37 Message: Logged In: YES user_id=644705 The point of this is that the buddy list keepalive isn't often enough in some circumstances. (Yes, the NAT is misconfigured, but it's not my NAT and I can't fix it!) I could add a global keepalive interval in GaimConnection, and let prpl maintainers use it or not at their whim, if that would be preferable. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-22 13:33 Message: Logged In: YES user_id=20979 Er, well it seems like you could add a preference to the preferences window... But I'm not sure that's really needed. After what Sean wrote, it sounds like maybe you could just implement gc->keepalive for IRC and make it so that it only sends the keepalive packet if your buddy list is empty. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-22 09:54 Message: Logged In: YES user_id=644705 If I add this option globally, it will require another field on the account options for EVERY builtin prpl. Will that really be acceptable? ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-21 17:41 Message: Logged In: YES user_id=199625 It took me a while to figure out why I was getting booted from Freenode, and then I discovered it was because my NAT wasn't keeping the connection open. Adding Nickserv to my buddy list *did* serve as a decent workaround. If that was the problem, you would be constantly kicked off other protocols such as AIM, as well, which would likewise need modification. gc->keepalive is certainly the correct place to send keepalive packets. -s. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-21 17:35 Message: Logged In: YES user_id=20979 I agree with Sean and Luke. I'm going to close this for now. If you take another stab at it, you may want to look into using gc->keepalive ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2005-06-21 10:16 Message: Logged In: YES user_id=28833 Sean is right. one minute *should* be enough. your NAT is badly configured ;-) that being said, I really have no basis on which to comment on this patch from a technical standpoint. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-21 09:17 Message: Logged In: YES user_id=644705 Once a minute is NOT enough, as evidenced by the fact that the workaround of putting someone on your buddy list isn't enough in several instances. It's on a per-irc-server basis now, because servers are *supposed* to ping their clients often enough to keep them alive; however, some (freenode) don't. ---------------------------------------------------------------------- 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-23 16:11:47
|
Patches item #1224386, was opened at 2005-06-20 15:21 Message generated for change (Comment added) made by eblanton 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: Closed Resolution: Rejected Priority: 5 Submitted By: Levi Bard (tak_tak) Assigned to: Ethan Blanton (eblanton) Summary: Global pref for keepalive ping Initial Comment: Patch to ping IRC servers at arbitrary intervals in order to prevent connections from dropping. ---------------------------------------------------------------------- >Comment By: Ethan Blanton (eblanton) Date: 2005-06-23 11:11 Message: Logged In: YES user_id=298616 I am inclined to agree. I think that IRC should support the keepalive (embodied in another patch), but honestly one should never need a keepalive shorter than many *minutes*; there is only so much network brokenness an IM client can fix. Ethan ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-23 10:50 Message: Logged In: YES user_id=20979 I think timing out connections within 30 seconds constitutes a broken network, and I don't think the addition of this preference is really justified. If you want opinions from more people, feel free to raise the issue on gaim-devel. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-23 10:38 Message: Logged In: YES user_id=644705 OK, this run is as a global network pref, and uses gc->keepalive. On a decent network, the default *should* be fine, but there are some networks bad enough where this is not the case. Screenshot at http://bard.sytes.net/global_ping_again.jpg ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-22 12:40 Message: Logged In: YES user_id=199625 I don't actually mean to make it a preference, but if you *did*, it would be a single option in Network, not multiple options for each protocol. Regardless, there is no NAT device that can't keep a connection open for at least a minute. Leaving it unconfigurable should be fine. -s. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-22 12:37 Message: Logged In: YES user_id=644705 The point of this is that the buddy list keepalive isn't often enough in some circumstances. (Yes, the NAT is misconfigured, but it's not my NAT and I can't fix it!) I could add a global keepalive interval in GaimConnection, and let prpl maintainers use it or not at their whim, if that would be preferable. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-22 12:33 Message: Logged In: YES user_id=20979 Er, well it seems like you could add a preference to the preferences window... But I'm not sure that's really needed. After what Sean wrote, it sounds like maybe you could just implement gc->keepalive for IRC and make it so that it only sends the keepalive packet if your buddy list is empty. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-22 08:54 Message: Logged In: YES user_id=644705 If I add this option globally, it will require another field on the account options for EVERY builtin prpl. Will that really be acceptable? ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-21 16:41 Message: Logged In: YES user_id=199625 It took me a while to figure out why I was getting booted from Freenode, and then I discovered it was because my NAT wasn't keeping the connection open. Adding Nickserv to my buddy list *did* serve as a decent workaround. If that was the problem, you would be constantly kicked off other protocols such as AIM, as well, which would likewise need modification. gc->keepalive is certainly the correct place to send keepalive packets. -s. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-06-21 16:35 Message: Logged In: YES user_id=20979 I agree with Sean and Luke. I'm going to close this for now. If you take another stab at it, you may want to look into using gc->keepalive ---------------------------------------------------------------------- Comment By: Luke Schierer (lschiere) Date: 2005-06-21 09:16 Message: Logged In: YES user_id=28833 Sean is right. one minute *should* be enough. your NAT is badly configured ;-) that being said, I really have no basis on which to comment on this patch from a technical standpoint. ---------------------------------------------------------------------- Comment By: Levi Bard (tak_tak) Date: 2005-06-21 08:17 Message: Logged In: YES user_id=644705 Once a minute is NOT enough, as evidenced by the fact that the workaround of putting someone on your buddy list isn't enough in several instances. It's on a per-irc-server basis now, because servers are *supposed* to ping their clients often enough to keep them alive; however, some (freenode) don't. ---------------------------------------------------------------------- Comment By: Sean Egan (seanegan) Date: 2005-06-20 15: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 15: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 15: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 |
3 messages has been excluded from this view by a project administrator.
