Pidgin

Whether Gaim uses gnome-keyring or plain-old -text passwords would better
fit into a compile time option even.
Otherwise, once gnome-keyring gets killed in some way, then Gaim would
suddenly start to save passwords in the old (plain-text) way. At least this
choosing of way to store passwords - should it be through gnome-keyring,
old-plain-text or some other way should not be done "too automatically".
One more note - is there any gnome-keyring alternative on windows?

On 12/25/06, Ruben Fonseca <krani1@...> wrote:
>
> On Fri, Dec 15, 2006 at 03:46:54PM -0600, Casey Harkins wrote:
> > Ethan Blanton wrote:
> >
> > >> BUT if we are going to tie into gnome when in gnome, we should
> consider
> > >> things like this.
> > >>
> > >> That being said, perhaps we should still reject this one as a given
> user
> > >> might not always be in gnome.  Thoughts?
> > >
> > > This is a very good point, as well -- if I understand it correctly,
> > > gnome-keyring only works when gnome-keyring-daemon is running, and
> > > clients won't start it themselves if the service does not already
> > > exist.
> > >
> >
> > This is one of the things I was planning on tackling at some point, just
> > haven't found the time to do it. SuSE also had a patched version of gaim
> > 1.5 with gnome-keyring support. I was planning adding some signals
> > wrapping the password get/set operations in gaim. The default behavior
> > would be the existing behavior. Plugins could then utilize these signals
> > to implement an alternative method for storing passwords.
>
> This is a *great* idea! I'd love to see this working.
>
> However, I don't thing this will thight the integration of Gaim with
> Gnome.
> Gaim could simply check if there is any gnome-keyring running and interact
> with
> it, falling back to the original system otherwise.
>
> I don't know if this is feasable or not, it is just a thought. Maybe the
> plugin
> option will work better :)
>
> ruben
>
> >
> > -casey
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Gaim-devel mailing list
> > Gaim-devel@...
> > https://lists.sourceforge.net/lists/listinfo/gaim-devel
>
> --
> ---------------------------------------
> Linux asgard 2.6.14-gentoo #2 PREEMPT
> ---------------------------------------
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
>
>
>
>


-- 
Martin

On Thu, Dec 28, 2006 at 11:24:26AM +0200, Martin Ott wrote:
> Whether Gaim uses gnome-keyring or plain-old -text passwords would better
> fit into a compile time option even.
> Otherwise, once gnome-keyring gets killed in some way, then Gaim would
> suddenly start to save passwords in the old (plain-text) way. At least this
> choosing of way to store passwords - should it be through gnome-keyring,
> old-plain-text or some other way should not be done "too automatically".
> One more note - is there any gnome-keyring alternative on windows?

If it needs to be compile time, it must NEVER HAPPEN.  Because then the
distros are stuck with the choice of either never enabling this, or
forcing gaim to only be useful in GNOME.  This is an unacceptable
choice.

luke

Luke Schierer wrote:
> On Thu, Dec 28, 2006 at 11:24:26AM +0200, Martin Ott wrote:
>> Whether Gaim uses gnome-keyring or plain-old -text passwords would better
>> fit into a compile time option even.
>> Otherwise, once gnome-keyring gets killed in some way, then Gaim would
>> suddenly start to save passwords in the old (plain-text) way. At least this
>> choosing of way to store passwords - should it be through gnome-keyring,
>> old-plain-text or some other way should not be done "too automatically".
>> One more note - is there any gnome-keyring alternative on windows?
> 
> If it needs to be compile time, it must NEVER HAPPEN.  Because then the
> distros are stuck with the choice of either never enabling this, or
> forcing gaim to only be useful in GNOME.  This is an unacceptable
> choice.
> 
> luke

I agree. I think if a plugin for gnome-keyring were enabled and 
gnome-keyring died, the plugin would warn the user of that fact, rather 
than silently reverting to the plain text behavior. Maybe disable 
storing of passwords until gnome-keyring is started or the plugin is 
disabled.

-casey

On Tuesday 26 December 2006 03:21, Evan Schoenberg wrote:

> In gadu-gadu, there are options for 'download from server', 'upload
> to server', etc. in the account actions.  It seems that download
> doesn't happen automatically.  Is that intended?  If so, why?

Yes, it's intended to be so. Mainly because I don't like automatic 
operations which modify important data. Also, in my opinion, manual 
upload/download of the buddy list is not so troublesome.

take care,
Bartosz

On Dec 26, 2006, at 7:16 AM, Evan Schoenberg wrote:

> On Dec 26, 2006, at 11:42 AM, Bartosz Oler wrote:
>
>> Yes, it's intended to be so. Mainly because I don't like automatic
>> operations which modify important data. Also, in my opinion, manual
>> upload/download of the buddy list is not so troublesome.
>
> Well, given that the other protocols in Gaim all (1) automatically  
> retrieve the buddy list from the server and (2) automatically apply  
> changes made by the user such as adding, moving, and deleting  
> buddies to the serverside list, it seems troublesome to me.  It's  
> not that selecting <Account> -> Load from Server / Save to Server is  
> hard itself; it's that there's no reason to expect that sort of  
> activity to be necessary in the context of Gaim, nor any clear  
> reason why such actions should need to exist.
>
> Anyone else agree / disagree / not care?

Agree, for the same reasons Evan points out -- from a UI perspective,  
there's absolutely no reason to think that you would need to perform  
these operations, as all of the other protocols sync this information.  
I have not used gadugadu for Gaim, but I do use it on Windows and Linux.

The only case I could see being made for these sync operations is if  
the official client includes them.

-Colin

On Tue, Dec 26, 2006 at 12:16:07PM -0500, Evan Schoenberg wrote:
> 
> On Dec 26, 2006, at 11:42 AM, Bartosz Oler wrote:
> 
> >Yes, it's intended to be so. Mainly because I don't like automatic
> >operations which modify important data. Also, in my opinion, manual
> >upload/download of the buddy list is not so troublesome.
> 
> Well, given that the other protocols in Gaim all (1) automatically  
> retrieve the buddy list from the server and (2) automatically apply  
> changes made by the user such as adding, moving, and deleting buddies  
> to the serverside list, it seems troublesome to me.  It's not that  

This isn't quite true.  Jabber does this, as doe AIM.  Yahoo should but
sometimes fails.  MSN is a notable exception though.  It asks you what
it should do when it detects differences.

Still, this should not be hidden in the account menu, it should be doing
SOMETHING automatically. The user should at least know that the server list
differs.

luke

On Dec 27, 2006, at 12:39 AM, Luke Schierer wrote:
> This isn't quite true.  Jabber does this, as doe AIM.  Yahoo should  
> but
> sometimes fails.  MSN is a notable exception though.  It asks you what
> it should do when it detects differences.

Just wanted to add that Sametime will also automatically synchronize  
the local list from a server copy of the list, mimicking the behavior  
of the original Sametime client

- siege

---
Christopher (siege) O'Brien
siege@...

On Tue, 26 Dec 2006 12:16:07 -0500, Evan Schoenberg wrote
> On Dec 26, 2006, at 11:42 AM, Bartosz Oler wrote:
> 
> > Yes, it's intended to be so. Mainly because I don't like automatic
> > operations which modify important data. Also, in my opinion, manual
> > upload/download of the buddy list is not so troublesome.
> 
> Well, given that the other protocols in Gaim all (1) automatically  
> retrieve the buddy list from the server and (2) automatically apply  
> changes made by the user such as adding, moving, and deleting 
> buddies  to the serverside list, it seems troublesome to me.  It's 
> not that  selecting <Account> -> Load from Server / Save to Server 
> is hard  itself; it's that there's no reason to expect that sort of 
> activity  to be necessary in the context of Gaim, nor any clear 
> reason why such  actions should need to exist.
> 
> Anyone else agree / disagree / not care?

I agree.

-Mark

On Wednesday 27 December 2006 06:39, Luke Schierer wrote:

> Still, this should not be hidden in the account menu, it should be doing
> SOMETHING automatically. The user should at least know that the server
> list differs.

AFAIK the original GG client doesn't support automatic upload/download nor 
difference detection. But the latter seems very reasonable and gives the 
best of both worlds: nothing is done behind users' backs and users won't 
forget to sync their changes.

Any strong objections to this approach?

take care,
Bartosz

On Tue, 2006-12-26 at 01:15 +0000, Ruben Fonseca wrote:
> My question is: if this patch will go to HEAD, shouldn't it be working? Or am I missing something with patch applying? Am I the first to report a problem with this?

First of all, the tarball was not intended to be applied to HEAD. That
said, I see no reason why it can't be.

> Any help apreciated :)

The soc-2006-msnp13 branch is a work in progress. The original student
hasn't done much work in a while (not to point finger at anyone of
course, it's a _summer_ of code project). I took some time to look at
the code, and the first feeling is that more cleanup is necessary. I may
get to it during the break, or I may not. At this point it's one of
those "you get to keep the pieces" thing.

I believe Sean said that he intends to merge the work to HEAD after
2.0.0 is released, at that point it will be more useful to the causal
users.

-khc

On Mon, Dec 25, 2006 at 05:50:23PM -0800, Ka-Hing Cheung wrote:
> On Tue, 2006-12-26 at 01:15 +0000, Ruben Fonseca wrote:
> > My question is: if this patch will go to HEAD, shouldn't it be working?=
 Or am I missing something with patch applying? Am I the first to report a =
problem with this?
>=20
> First of all, the tarball was not intended to be applied to HEAD. That
> said, I see no reason why it can't be.
>=20
> > Any help apreciated :)
>=20
> The soc-2006-msnp13 branch is a work in progress. The original student
> hasn't done much work in a while (not to point finger at anyone of
> course, it's a _summer_ of code project). I took some time to look at
> the code, and the first feeling is that more cleanup is necessary. I may
> get to it during the break, or I may not. At this point it's one of
> those "you get to keep the pieces" thing.

Is there any information on the web about this new protocol? Or it was pure
reverse engineering?

>=20
> I believe Sean said that he intends to merge the work to HEAD after
> 2.0.0 is released, at that point it will be more useful to the causal
> users.

Ok, we'll wait :)

R=FAben

--=20
---------------------------------------
 Linux asgard 2.6.14-gentoo #2 PREEMPT
---------------------------------------

On Tue, Dec 26, 2006 at 04:51:40PM +0000, Ruben Fonseca wrote:
> On Mon, Dec 25, 2006 at 05:50:23PM -0800, Ka-Hing Cheung wrote:
> > On Tue, 2006-12-26 at 01:15 +0000, Ruben Fonseca wrote:
> > > My question is: if this patch will go to HEAD, shouldn't it be workin=
g? Or am I missing something with patch applying? Am I the first to report =
a problem with this?
> >=20
> > First of all, the tarball was not intended to be applied to HEAD. That
> > said, I see no reason why it can't be.
> >=20
> > > Any help apreciated :)
> >=20
> > The soc-2006-msnp13 branch is a work in progress. The original student
> > hasn't done much work in a while (not to point finger at anyone of
> > course, it's a _summer_ of code project). I took some time to look at
> > the code, and the first feeling is that more cleanup is necessary. I may
> > get to it during the break, or I may not. At this point it's one of
> > those "you get to keep the pieces" thing.
>=20
> Is there any information on the web about this new protocol? Or it was pu=
re
> reverse engineering?

Never mind, google found it http://msnpiki.msnfanatic.com/index.php/MSN_Pro=
tocol_Version_13 .

>=20
> >=20
> > I believe Sean said that he intends to merge the work to HEAD after
> > 2.0.0 is released, at that point it will be more useful to the causal
> > users.
>=20
> Ok, we'll wait :)
>=20
> R=FAben
>=20
> --=20
> ---------------------------------------
>  Linux asgard 2.6.14-gentoo #2 PREEMPT
> ---------------------------------------



> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel


--=20
---------------------------------------
 Linux asgard 2.6.14-gentoo #2 PREEMPT
---------------------------------------

On Mon, 2006-12-25 at 18:42 -0800, evands@... wrote:
> +gaim_notify_user_info_entry_set_value(GaimNotifyUserInfoEntry *user_info_entry, const char *value)
> +{
> +	g_return_if_fail(user_info_entry != NULL);
> +
> +	if (value != user_info_entry->value)
> +	{
> +		g_free(user_info_entry->value);
> +		user_info_entry->value = g_strdup(value);
> +	}
> +}

> +void
> +gaim_notify_user_info_entry_set_value(GaimNotifyUserInfoEntry *user_info_entry, GaimNotifyUserInfoEntryType type)
> +{
> +	g_return_if_fail(user_info_entry != NULL);
> +
> +	user_info_entry->type = type;
> +}

I think you mean set_type for the second one. Also, there's no way to
remove entries. Operating on the GList * is not sufficient since the
pointer may change when entries are removed.

-khc

> +GaimNotifyUserInfoEntryType
> +gaim_notify_user_info_entry_get_type(GaimNotifyUserInfoEntry
> *user_info_entry)
> +{
> +       g_return_val_if_fail(user_info_entry != NULL, NULL);
> +
> +       return user_info_entry->type;
> +}



My compiler grumbled about the NULL return.

-Mark

Richard Laager spake unto us the following wisdom:
> On Thu, 2006-12-21 at 23:55 -0500, Ethan Blanton wrote:
> > What our conversation boiled down to, was that it would be nice if
> > Gaim had a "session" plugin, which remembered open conversations, and
> > could reopen them on gaim startup.  (In this user's case, particularly
> > conversations which we suspect have unread messages -- which I realize
> > will have to be a heuristic.)
>=20
> I like this one. If this integrated with the GNOME session management,
> I'd be a happy camper. Also, it should also restore the previous status,
> regardless of the "use status on startup" preference, I think...

Saving sessions as per an X session manager is somewhat different from
what I was looking for, but also interesting -- that would mean you
could snapshot Gaim's state at _any time_ and restore that state
later.  That's more ambitious than I was thinking.  Saved status is
also more ambitious than I was thinking.

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

On 12/22/06, Ethan Blanton <eblanton@...> wrote:
> Saving sessions as per an X session manager is somewhat different from
> what I was looking for, but also interesting -- that would mean you
> could snapshot Gaim's state at _any time_ and restore that state
> later.  That's more ambitious than I was thinking.  Saved status is
> also more ambitious than I was thinking.

My implementation was to create a directory in .gaim/, attach to the
conversation-write signal, and write HTML into a file per
conversation. The file gets unlinked when the conversation is
destroyed, and when the plugin loads, it creates conversations for all
the files and writes the HTML into it.

-s.