Pidgin

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

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

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

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

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

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

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

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

Patches item #1180490, was opened at 2005-04-11 00:10
Message generated for change (Comment added) made by rlaager
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: Richard Laager (rlaager)
Date: 2005-06-23 00:50

Message:
Logged In: YES 
user_id=156487

What do you mean "show matching aliases"? 

----------------------------------------------------------------------

Comment By: Mark Doliner (thekingant)
Date: 2005-06-22 22: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 20: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 14: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 13: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-17 23: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 10: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 09: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 00: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

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

Patches item #1180490, was opened at 2005-04-11 00:10
Message generated for change (Comment added) made by rlaager
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: Richard Laager (rlaager)
Date: 2005-06-23 11:08

Message:
Logged In: YES 
user_id=156487

Yes. 

----------------------------------------------------------------------

Comment By: Mark Doliner (thekingant)
Date: 2005-06-23 07: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 00:50

Message:
Logged In: YES 
user_id=156487

What do you mean "show matching aliases"? 

----------------------------------------------------------------------

Comment By: Mark Doliner (thekingant)
Date: 2005-06-22 22: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 20: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 14: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 13: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-17 23: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 10: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 09: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 00: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

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

Patches item #1224386, was opened at 2005-06-20 16:21
Message generated for change (Comment added) made by thekingant
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: 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

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

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

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: Closed
Resolution: Rejected
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-23 08:48

Message:
Logged In: YES 
user_id=1298580

indeed, auto-ellipsizing is the best idea. it was definetly
my first choice but as a beginner i don't quite know where
to start on implementing it. but as for the other stuff...
i have a lot of friends using gaim and they share the same
annoyance i do about not being able to see their statuses.
the only reason they use big view is so that they can see
the statuses. so showing status in small view can be useful
too, and besides, with auto-ellipsizing and having the
status text grayed out, the people you talk about (who want
it compact etc) won't even notice it's there. i can't recall
all the times i had to hover over a friend (in small view)
just to see their status... really annoying.
also, as a (former) yahoo user, i've found myself many times
wanting to leave a message to someone offline and just
thinking 'oh damn, gotta use the mouse again' (btw, i didn't
say anything about toggling empty groups). and how much can
a CTRL+O mapping annoy someone who didn't want it? he just
won't use it.
oh the other hand, i fully respect the fact that gaim should
have its own personality, but still, users switching to gaim
from their default msn, yahoo etc clients need to feel at
home with gaim and so they need to have as many of the
features they were used to as possible.
in conclusion, all i ask is that you take into consideration
that some people would/may like these features (not
necessarily in the form i've submitted them).

----------------------------------------------------------------------

Comment By: Mark Doliner (thekingant)
Date: 2005-06-23 02:49

Message:
Logged In: YES 
user_id=20979

I definitely don't like having a keyboard shortcut to toggle
showing offline buddies and empty groups.  In fact, I'm
going to remove that from CVS HEAD.

I think changing 20 to 30 might cause people to complain
that their buddy list is too wide, and I don't think I want
to change that.  However, it might be possible to have gtk
auto ellipsize this.

And as for showing the status text in the small buddy
list... I think this is a bad idea.  The small buddy list
should be small and simple and the big buddy list should be
compact.  From what I've seen, people who use the compact
layout tend to REALLY like things to be compact and useless,
and I'm not sure changing that is a good idea.

----------------------------------------------------------------------

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