pidgin-devel — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel

Re: [Gaim-devel] Password Obfuscation/Encryption in .gaimrc

[John B. S. <jo...@si...>]

There's some merit to the idea of a passkey to unlock your encrypted keys=
 -=20
this takes care of the problem I was just going to mention.  Barring this=
=20
idea, encryption in the rc file is completely moot based on the fact that=
 you=20
could just copy it to another account, run Gaim, and change the passwords=
,=20
without ever seeing, or trying to decrypt the 'encrypted passwords.'

John Silvestri

On Thursday 10 October 2002 06:44 pm, Michael Lasevich wrote:
> What is being asked is a bit of obfuscation , not perfect bulletproof
> encryption. A dedicated person can always get around any encryption sch=
eme
> there is. If someone has physical access to my linux box they can have
> root-level permissions in minutes - that does not mean I leave my root
> password on a post it note glued to my monitor. Just because someone ca=
n
> easily find means of decoding the passwords, does not mean they should =
be
> available in plain view to anyone who happens to glance at the rc file.

Re: [Gaim-devel] Password Obfuscation/Encryption in .gaimrc

[Luke S. <lsc...@gm...>]

On Thu, Oct 10, 2002 at 03:44:31PM -0700, Michael Lasevich wrote:
> I've just read the discussion about password encryption (libyahoo2
> integration thread) and I must say that I find the attitude of the
> developers on this subject a bit silly.
> 
> What is being asked is a bit of obfuscation , not perfect bulletproof
> encryption. A dedicated person can always get around any encryption scheme
> there is. If someone has physical access to my linux box they can have
> root-level permissions in minutes - that does not mean I leave my root
> password on a post it note glued to my monitor. Just because someone can
> easily find means of decoding the passwords, does not mean they should be
> available in plain view to anyone who happens to glance at the rc file.
> 
> Besides, noone in the discussion mentioned the obvious solution of having
> all passwords encrypted by a single password you have to type in at start
> time. This will eliminate every reason given against encryption in the
> thread.

because if we did that we'd have to take care of 2 side effect cases:
1)alot of people will not want to remember any password for their im.
this means the encryption must be optional. 
2)people who enable it then want to disable it. along these lines, people
who forget the passphrase. this makes doing it less trivial. 

> 
> All that being said, I am not writing to start another flame war here. I
> respect the developers descision even if I do not agree. It is their
> decision to make. But this is an open source project and I was just
> wondering that since it was mentioned that many people submitted patches to
> solve this issue, can I get some pointers to those patches? I am not a real

i've never seen a patch. only requests. and some demands. 

luke

> programmer and thus make it a rule not to edit software unless I absolutely
> have to - I'd rather not have to mess with gaim source code. Has someone on
> this list written/have such a patch they can send me?
> 
> 
> Thank you.
> 
> -Michael
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

-- 
-This email is made of 100% recycled electrons.

Re: [Gaim-devel] Password Obfuscation/Encryption in .gaimrc

[Rob F. <ro...@ma...>]

I've already sent an e-mail somewhere saying that I will take care of
this.

[Gaim-devel] Password Obfuscation/Encryption in .gaimrc

[Michael L. <ma...@la...>]

I've just read the discussion about password encryption (libyahoo2
integration thread) and I must say that I find the attitude of the
developers on this subject a bit silly.

What is being asked is a bit of obfuscation , not perfect bulletproof
encryption. A dedicated person can always get around any encryption scheme
there is. If someone has physical access to my linux box they can have
root-level permissions in minutes - that does not mean I leave my root
password on a post it note glued to my monitor. Just because someone can
easily find means of decoding the passwords, does not mean they should be
available in plain view to anyone who happens to glance at the rc file.

Besides, noone in the discussion mentioned the obvious solution of having
all passwords encrypted by a single password you have to type in at start
time. This will eliminate every reason given against encryption in the
thread.

All that being said, I am not writing to start another flame war here. I
respect the developers descision even if I do not agree. It is their
decision to make. But this is an open source project and I was just
wondering that since it was mentioned that many people submitted patches to
solve this issue, can I get some pointers to those patches? I am not a real
programmer and thus make it a rule not to edit software unless I absolutely
have to - I'd rather not have to mess with gaim source code. Has someone on
this list written/have such a patch they can send me?


Thank you.

-Michael

Re: [Gaim-devel] Really huge time stamp font in jabber conference

[Luke S. <lsc...@gm...>]

this has to do with your default gtk font. the message has a font tag
manipluating the size, but the timestamp does not, and so uses the
default size, which is set large on your system. you can chage this by
editing ~/.gtkrc
luke

On Thu, Oct 10, 2002 at 05:21:39PM +0200, Xavier Bachelot wrote:
> Hello list,
> 
> When connecting to a jabber conference through Gaim, I got very huge 
> time stamp font. (I'm using latest Gaim rpm build 0.59.4)
> 
> The Jabber server is version 1.4.2 and there don't seem to be problems 
> with other IM clients.
> 
> Is there a pref to modify or something or is this a bug ?
> 
> Regards,
> 
> Xavier
> 
> -- 
> ------------------------------------------------------------------------
> ! Xavier Bachelot      FR Workstations Support & System Administration !
> ! Kelkoo.com                                                           !
> !             |||                    mail : xav...@ke... !
> !            (@ @)      Phone: +(33) 04 76 29 76 24 - AIM : schlobinux !
> ----------oOO-(_)-OOo---------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

-- 
-This email is made of 100% recycled electrons.

[Gaim-devel] Really huge time stamp font in jabber conference

[Xavier B. <xav...@ke...>]

Hello list,

When connecting to a jabber conference through Gaim, I got very huge 
time stamp font. (I'm using latest Gaim rpm build 0.59.4)

The Jabber server is version 1.4.2 and there don't seem to be problems 
with other IM clients.

Is there a pref to modify or something or is this a bug ?

Regards,

Xavier

-- 
------------------------------------------------------------------------
! Xavier Bachelot      FR Workstations Support & System Administration !
! Kelkoo.com                                                           !
!             |||                    mail : xav...@ke... !
!            (@ @)      Phone: +(33) 04 76 29 76 24 - AIM : schlobinux !
----------oOO-(_)-OOo---------------------------------------------------

Re: [Gaim-devel] docklet patch: update status on first rcvd message

[Sean E. <se...@se...>]

I did the same exact thing--and then didn't commit it.  Why do I do that
all the time?

Oh, I remember now.  Oh well--I'll commit it anyway.

Thanks, Derek.

-s.

On Wed, 2002-09-25 at 03:06, Derek Ireland wrote:
> Hello,
> 
> I have been using the CVS version of gaim (0.60cvs)
> with the docklet and noticed that it does not
> update to the unread_pending state on the arrival
> of only one message.
> 
> The code in docklet.c that checks reads
>                 if (unread_message_queue) {
>                         status = unread_pending;
>                 } else if (awaymessage) {
> 
> now, the docklet plugin registers to get
> event_im_recv events, which are sent
> by function serv_got_im in server.c
> *before* the unread_message_queue is updated.
> 
> Thats bad.
> 
> However after the unread_message_queue is
> updated serv_got_im sends an 
> event_im_displayed_rcvd.
> 
> Thats good.
> 
> But the event is not registered by the docklet.
> 
> Thats bad.
> 
> So, here is what I did to fix it.
> 
> RCS file:
> /cvsroot/gaim/gaim/plugins/docklet/docklet.c,v
> retrieving revision 1.5
> diff -u -r1.5 docklet.c
> --- docklet.c	16 Sep 2002 08:35:16 -0000	1.5
> +++ docklet.c	25 Sep 2002 06:47:26 -0000
> @@ -332,6 +332,7 @@
>  	gaim_signal_connect(handle, event_connecting,
> gaim_connecting, NULL);
>  	gaim_signal_connect(handle, event_away, gaim_away,
> NULL);
>  	gaim_signal_connect(handle, event_im_recv,
> gaim_im_recv, NULL);
> +	gaim_signal_connect(handle, event_im_displayed_rcvd,
> gaim_im_recv, NULL);
>  	gaim_signal_connect(handle, event_buddy_signon,
> gaim_buddy_signon, NULL);
>  	gaim_signal_connect(handle, event_buddy_signoff,
> gaim_buddy_signoff, NULL);
>  	gaim_signal_connect(handle, event_buddy_away,
> gaim_buddy_away, NULL);
> 
> 
> I hope its good?
> 
> Derek
> 
> 
> http://mobile.yahoo.com.au - Yahoo! Messenger for SMS
> - Always be connected to your Messenger Friends
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
> 

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Sean E. <se...@se...>]

On Tue, 2002-10-01 at 00:48, Rob Flynn wrote:

> I started looking at how FT works in MSN and IRC.  I talked VERY briefly
> about Yahoo FT support w/ Sean.

I should still have my own DCC transfer patches from way back when if
you want them.

-s.

Re: [Gaim-devel] find_prpl() returns NULL

[Rob F. <ro...@ma...>]

On Mon, 2002-10-07 at 21:45, Luke Schierer wrote:
> with bash, i believe the command is 
> ulimit -c unlimited
> luke

Correct.

Re: [Gaim-devel] find_prpl() returns NULL

[Luke S. <lsc...@gm...>]

with bash, i believe the command is 
ulimit -c unlimited
luke

On Mon, Oct 07, 2002 at 06:38:34PM -0700, David W. Maust wrote:
> find_prpl(user->protocol) is returning NULL in the gaim CVS when I use
> it on Red Hat Linux 8.0.  My system is not configured to do core dumps. 
> How would you turn that on?
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

-- 
-This email is made of 100% recycled electrons.

[Gaim-devel] find_prpl() returns NULL

[David W. M. <dm...@dm...>]

find_prpl(user->protocol) is returning NULL in the gaim CVS when I use
it on Red Hat Linux 8.0.  My system is not configured to do core dumps. 
How would you turn that on?

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Robert M. <rob...@de...>]

On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:
> Like a lot of people, I've been wanting Oscar File Transfer support in
> gaim.  So like fewer people, I did something about it.  Now I'm ready to
> toss my patch on the file-xfer pile.

Yeesh, typical! File transfer patches are like buses. You wait ages for
one, and then two come along at once! :P

Regards,
Rob

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Luke S. <lsc...@gm...>]

On Tue, Oct 01, 2002 at 08:44:54AM -0400, Brian Ferris wrote:
> On the issue of threading, moving data handler out from its own thread
> and back into the g_main_loop io handler is a relatively easy task for
> my patch, as this is how I originally had it working.  However, file
> transfer tended to dominate the loop in that case, thus non-blocking
> sockets.

non-blocking sockets are most certainly needed for gaim in general.

> 
> As for the UI concerns, I would say this.  First, the only two pieces of
> information I care about in a given transfer is the percent complete and
> how much longer I have to go.  I keep my buddy list pretty narrow and in
> those cases, that's all I see (the file name is truncated, perhaps
> right-justifying that field would indicate enough of the unique file
> name on long paths to still be useful).  If I want to know more about
> the transfer, I do a mouse-over on the transfer entry, which brings up a
> tooltip with more extensive info (I couldn't figure out how to screen
> cap a tooltip to show this).

tooltips are a pain.

> 
> Secondly, though my buddy list is already pretty long, I can see how it
> would be nice to have transfer info in a dialog as well.  Mark Doliner
> suggested that a dialog similar to the one used by Galeon (he sent me
> this as an example:  http://www4.ncsu.edu/~bdferris/Thing.jpg ).  I

this looks good.

> think this could whipped up pretty quickly using the current code I have
> written, so I will attempt to do so.  I'd still like to leave the option
> of the nested UI elements, since I'm a big fan of not-so-many-dialogs.

that's fine, but make the separate dialog the default. 

> 
> Thirdly, it sounds like major changes are being made to the buddy list
> UI model.  In light of ever-growing buddy lists, how hard would it be to
> implement sorted buddy lists?  Aka, all active buddies float to the top
> of the list while my buddy who has been idle for three days is hidden at
> the bottom.  Just a thought.

the buddy list is being entirely redone. sorting members on the current model is
possible, but not worth the effort at this point. as things progress, sorting will be
added in as well.
luke

> 
> Brian Ferris
> 
> On Tue, 2002-10-01 at 02:01, Christian Hammond wrote:
> > On Tue, Oct 01, 2002 at 01:52:02AM -0400, William T. Mahan wrote:
> > > On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:
> > > > -Threaded for your pleasure
> > > 
> > > Mine isn't threaded, mainly because I didn't see any other threading
> > > in the Gaim code.  Is anyone strongly for or against using threads?
> > 
> > Threading presents all kinds of fun little problems, especially with
> > debugging. What we would prefer is a setup for non-blocking sockets.
> > This is not easy, though, which is why we're giving the job to Ethan
> > Blanton!
> > 
> > > > -A handy way of displaying active transfers as sub-entries in the buddy
> > > > list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).
> > > 
> > > This looks nice--Brian's patch obviously has a more advanced GUI than
> > > mine right now.  I don't have a progress bar, ETA, etc., although I
> > > think Rob Flynn said he had some ideas about a generic file transfer
> > > interface.
> > 
> > Though this interface does indeed look nice, it requires a wide buddy
> > list, which most people do not prefer. It may be better in the long
> > run to just have a file transfer dialog, though it'd be nice if this
> > was made an option (if it wasn't too much work, that is). I think if
> > we had a different model for the buddy list (internal and API), it
> > could be worked in a bit better, but I don't want to go into detail
> > about that.
> > 
> > > > This patch is different from the one under development by "wmahan".
> > > > Instead of fixing the code in ft.c, I went from scratch. The only thing
> > > > this patch offers in the way of innovation (oft is oft is oft) is the
> > > > nested transfer UI element.  As far as I can tell, I kept the UI
> > > > code
> > > 
> > > Yes, it looks like our approaches our fairly different.  But I've
> > > already talked to Brian about possible future collaboration, in the
> > > hope that Gaim will benefit regardless of which patch is ultimately
> > > accepted.
> > 
> > It's good that you two are discussing this together. I don't know what
> > Sean and Rob's stance on the incorporation of file transfer patches
> > is, but I would imagine it would help if there were people working
> > with you on developing file transfer support for other protocols.
> > 
> > Christian
> > 
> > -- 
> > Christian Hammond         <>  The GNUpdate Project
> > ch...@gn...      <>  http://www.gnupdate.org/
> >    My software never contains bugs. It just develops random features.
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> > Linux or FreeBSD, FREE setup, FAST network. Get your own server 
> > today at http://www.ServePath.com/indexfm.htm
> > _______________________________________________
> > Gaim-devel mailing list
> > Gai...@li...
> > https://lists.sourceforge.net/lists/listinfo/gaim-devel
> -- 
> Privacy never seems all that important till it's gone.
> For the initiated:  PGP KeyID 0xF8EA3348
> For the interested: http://www.gnupg.org/



-- 
-This email is made of 100% recycled electrons.

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Brian F. <bdf...@un...>]

On the issue of threading, moving data handler out from its own thread
and back into the g_main_loop io handler is a relatively easy task for
my patch, as this is how I originally had it working.  However, file
transfer tended to dominate the loop in that case, thus non-blocking
sockets.

As for the UI concerns, I would say this.  First, the only two pieces of
information I care about in a given transfer is the percent complete and
how much longer I have to go.  I keep my buddy list pretty narrow and in
those cases, that's all I see (the file name is truncated, perhaps
right-justifying that field would indicate enough of the unique file
name on long paths to still be useful).  If I want to know more about
the transfer, I do a mouse-over on the transfer entry, which brings up a
tooltip with more extensive info (I couldn't figure out how to screen
cap a tooltip to show this).

Secondly, though my buddy list is already pretty long, I can see how it
would be nice to have transfer info in a dialog as well.  Mark Doliner
suggested that a dialog similar to the one used by Galeon (he sent me
this as an example:  http://www4.ncsu.edu/~bdferris/Thing.jpg ).  I
think this could whipped up pretty quickly using the current code I have
written, so I will attempt to do so.  I'd still like to leave the option
of the nested UI elements, since I'm a big fan of not-so-many-dialogs.

Thirdly, it sounds like major changes are being made to the buddy list
UI model.  In light of ever-growing buddy lists, how hard would it be to
implement sorted buddy lists?  Aka, all active buddies float to the top
of the list while my buddy who has been idle for three days is hidden at
the bottom.  Just a thought.

Brian Ferris

On Tue, 2002-10-01 at 02:01, Christian Hammond wrote:
> On Tue, Oct 01, 2002 at 01:52:02AM -0400, William T. Mahan wrote:
> > On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:
> > > -Threaded for your pleasure
> >=20
> > Mine isn't threaded, mainly because I didn't see any other threading
> > in the Gaim code.  Is anyone strongly for or against using threads?
>=20
> Threading presents all kinds of fun little problems, especially with
> debugging. What we would prefer is a setup for non-blocking sockets.
> This is not easy, though, which is why we're giving the job to Ethan
> Blanton!
>=20
> > > -A handy way of displaying active transfers as sub-entries in the bud=
dy
> > > list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).
> >=20
> > This looks nice--Brian's patch obviously has a more advanced GUI than
> > mine right now.  I don't have a progress bar, ETA, etc., although I
> > think Rob Flynn said he had some ideas about a generic file transfer
> > interface.
>=20
> Though this interface does indeed look nice, it requires a wide buddy
> list, which most people do not prefer. It may be better in the long
> run to just have a file transfer dialog, though it'd be nice if this
> was made an option (if it wasn't too much work, that is). I think if
> we had a different model for the buddy list (internal and API), it
> could be worked in a bit better, but I don't want to go into detail
> about that.
>=20
> > > This patch is different from the one under development by "wmahan".
> > > Instead of fixing the code in ft.c, I went from scratch. The only thi=
ng
> > > this patch offers in the way of innovation (oft is oft is oft) is the
> > > nested transfer UI element.  As far as I can tell, I kept the UI
> > > code
> >=20
> > Yes, it looks like our approaches our fairly different.  But I've
> > already talked to Brian about possible future collaboration, in the
> > hope that Gaim will benefit regardless of which patch is ultimately
> > accepted.
>=20
> It's good that you two are discussing this together. I don't know what
> Sean and Rob's stance on the incorporation of file transfer patches
> is, but I would imagine it would help if there were people working
> with you on developing file transfer support for other protocols.
>=20
> Christian
>=20
> --=20
> Christian Hammond         <>  The GNUpdate Project
> ch...@gn...      <>  http://www.gnupdate.org/
>    My software never contains bugs. It just develops random features.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> Linux or FreeBSD, FREE setup, FAST network. Get your own server=20
> today at http://www.ServePath.com/indexfm.htm
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
--=20
Privacy never seems all that important till it's gone.
For the initiated:  PGP KeyID 0xF8EA3348
For the interested: http://www.gnupg.org/

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Luke S. <lsc...@gm...>]

On Mon, Sep 30, 2002 at 11:01:25PM -0700, Christian Hammond wrote:
> On Tue, Oct 01, 2002 at 01:52:02AM -0400, William T. Mahan wrote:
> > On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:

> > > -A handy way of displaying active transfers as sub-entries in the buddy
> > > list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).
> > 
> > This looks nice--Brian's patch obviously has a more advanced GUI than
> > mine right now.  I don't have a progress bar, ETA, etc., although I
> > think Rob Flynn said he had some ideas about a generic file transfer
> > interface.
> 
> Though this interface does indeed look nice, it requires a wide buddy
> list, which most people do not prefer. It may be better in the long
> run to just have a file transfer dialog, though it'd be nice if this
> was made an option (if it wasn't too much work, that is). I think if
> we had a different model for the buddy list (internal and API), it
> could be worked in a bit better, but I don't want to go into detail
> about that.

also, some of us already cannot see the entire buddy list at one time, making it
longer for non-buddy items is less than ideal for such people. you'd be unable to see
the status of things w/out scrolling around. i'm in favor for an at least optional
dialog also. 

luke
-- 
-This email is made of 100% recycled electrons.
-If something can go wrong.... FIX IT!
 If it's Microsoft...delete it.
-There are three ways to get something done:
   (1) Do it yourself.
   (2) Hire someone to do it for you.
   (3) Forbid your kids to do it.

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Rob F. <ro...@ma...>]

> 
> Though this interface does indeed look nice, it requires a wide buddy
> list, which most people do not prefer. It may be better in the long
> run to just have a file transfer dialog, though it'd be nice if this
> was made an option (if it wasn't too much work, that is). I think if
> we had a different model for the buddy list (internal and API), it
> could be worked in a bit better, but I don't want to go into detail
> about that.

I should have my UI completed soon. Some things happened this weekend
that kept me from coding much on it. I'll post something here about it
when I get finished so you all can give me your input.


> It's good that you two are discussing this together. I don't know what
> Sean and Rob's stance on the incorporation of file transfer patches
> is, but I would imagine it would help if there were people working
> with you on developing file transfer support for other protocols.

I started looking at how FT works in MSN and IRC.  I talked VERY briefly
about Yahoo FT support w/ Sean.

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Nathan W. <fac...@fa...>]

> It's good that you two are discussing this together. I don't know what
> Sean and Rob's stance on the incorporation of file transfer patches
> is, but I would imagine it would help if there were people working
> with you on developing file transfer support for other protocols.

If we get the start of an interface going, i'll see what I can do about
jabber file transfer.  It doesn't look to be too difficult, but I don't
feel like designing an interface.  Ball is in Rob's court, I guess.

--=20
Nathan Walp             || fac...@fa...
GPG Fingerprint:        ||   http://faceprint.com/
5509 6EF3 928B 2363 9B2B  DA17 3E46 2CDC 492D DB7E

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Christian H. <ch...@gn...>]

On Tue, Oct 01, 2002 at 01:52:02AM -0400, William T. Mahan wrote:
> On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:
> > -Threaded for your pleasure
> 
> Mine isn't threaded, mainly because I didn't see any other threading
> in the Gaim code.  Is anyone strongly for or against using threads?

Threading presents all kinds of fun little problems, especially with
debugging. What we would prefer is a setup for non-blocking sockets.
This is not easy, though, which is why we're giving the job to Ethan
Blanton!

> > -A handy way of displaying active transfers as sub-entries in the buddy
> > list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).
> 
> This looks nice--Brian's patch obviously has a more advanced GUI than
> mine right now.  I don't have a progress bar, ETA, etc., although I
> think Rob Flynn said he had some ideas about a generic file transfer
> interface.

Though this interface does indeed look nice, it requires a wide buddy
list, which most people do not prefer. It may be better in the long
run to just have a file transfer dialog, though it'd be nice if this
was made an option (if it wasn't too much work, that is). I think if
we had a different model for the buddy list (internal and API), it
could be worked in a bit better, but I don't want to go into detail
about that.

> > This patch is different from the one under development by "wmahan".
> > Instead of fixing the code in ft.c, I went from scratch. The only thing
> > this patch offers in the way of innovation (oft is oft is oft) is the
> > nested transfer UI element.  As far as I can tell, I kept the UI
> > code
> 
> Yes, it looks like our approaches our fairly different.  But I've
> already talked to Brian about possible future collaboration, in the
> hope that Gaim will benefit regardless of which patch is ultimately
> accepted.

It's good that you two are discussing this together. I don't know what
Sean and Rob's stance on the incorporation of file transfer patches
is, but I would imagine it would help if there were people working
with you on developing file transfer support for other protocols.

Christian

-- 
Christian Hammond         <>  The GNUpdate Project
ch...@gn...      <>  http://www.gnupdate.org/
   My software never contains bugs. It just develops random features.

Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[William T. M. <wt...@du...>]

On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:
> 
> -Send and receive single files, multiple files, directories, and even
> have multiple OFT sessions going for the same buddy

For comparison, the same applies to my patch except for sending
multiple files (I'm working on that).

> -Threaded for your pleasure

Mine isn't threaded, mainly because I didn't see any other threading
in the Gaim code.  Is anyone strongly for or against using threads?

> -A handy way of displaying active transfers as sub-entries in the buddy
> list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).

This looks nice--Brian's patch obviously has a more advanced GUI than
mine right now.  I don't have a progress bar, ETA, etc., although I
think Rob Flynn said he had some ideas about a generic file transfer
interface.

> This patch is different from the one under development by "wmahan".
> Instead of fixing the code in ft.c, I went from scratch. The only thing
> this patch offers in the way of innovation (oft is oft is oft) is the
> nested transfer UI element.  As far as I can tell, I kept the UI
> code

Yes, it looks like our approaches our fairly different.  But I've
already talked to Brian about possible future collaboration, in the
hope that Gaim will benefit regardless of which patch is ultimately
accepted.

> completely out of the oscar protocol tree, but I did make some
> significant additions to core gaim code.  I'm all for joining forces
> with other OFT efforts if need be.

I'm always glad to have some friendly competition. :)  I'll try to
take a more detailed look at your code when I get a chance.

-- Wil

[Gaim-devel] Yet Another Oscar File Transfer Patch

[Brian F. <bdf...@un...>]

Like a lot of people, I've been wanting Oscar File Transfer support in
gaim.  So like fewer people, I did something about it.  Now I'm ready to
toss my patch on the file-xfer pile.

Notable features include:

-Send and receive single files, multiple files, directories, and even
have multiple OFT sessions going for the same buddy
-Threaded for your pleasure
-A handy way of displaying active transfers as sub-entries in the buddy
list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).

This patch is different from the one under development by "wmahan".
Instead of fixing the code in ft.c, I went from scratch. The only thing
this patch offers in the way of innovation (oft is oft is oft) is the
nested transfer UI element.  As far as I can tell, I kept the UI code
completely out of the oscar protocol tree, but I did make some
significant additions to core gaim code.  I'm all for joining forces
with other OFT efforts if need be.

I hope that somebody might find this patch useful.  Note:  I put the
patch up in the "Patches" area.

Thanks,
Brian Ferris
SN: Slackrat2k


Usage Notes:

Currently, saved files are automatically put in
.gaim/Downloads/BuddyName/. Right now this isn't configurable unless you
recompile (annoying, I agree, but I haven't tackled adding new
Preference options yet).

Other things to watch out for... sending directories between Windows and
*nix machines might be a bit tricky since I still refer to '/' as the
directory separator.

Beyond that it seems to work nicely. Hopefully you
will let me know. Build against 0.60cvs.

Re: [Gaim-devel] Trivial patch: sprintf -> snprintf

[Luke S. <lsc...@gm...>]

On Sun, Sep 29, 2002 at 04:38:54PM -0400, William T. Mahan wrote:
> Hi,
> 
> While working with the Oscar prpl I came across a few places that used
> sprintf with a fixed-size buffer.  I don't think this is a big deal
> because the untrusted data usually passes through the BOS server,
> which probably places restrictions on the lengths of screennames and
> the like.
> 
> However, it doesn't appear that Gaim checks the lengths of incoming
> TLVs, and now that direct TCP connections to other clients are
> supported, I think it's important to handle any outside data
> carefully.  The attached patch changes the sprintf()s to snprintf()s.
> 
> Also, if this is not the best place for someone without CVS commit
> access to send these sorts of small patches, just let me
> know.

sending patches here is fine, especially for bug fix patches. posting
them to sourceforge though allows people to test patches that we might
want to wait a while before committing, if, say, other things are
happening to the body of code modified at the time.
luke



-- 
-This email is made of 100% recycled electrons.
-If something can go wrong.... FIX IT!
 If it's Microsoft...delete it.
-There are three ways to get something done:
   (1) Do it yourself.
   (2) Hire someone to do it for you.
   (3) Forbid your kids to do it.

[Gaim-devel] Trivial patch: sprintf -> snprintf

[William T. M. <wt...@du...>]

Hi,

While working with the Oscar prpl I came across a few places that used
sprintf with a fixed-size buffer.  I don't think this is a big deal
because the untrusted data usually passes through the BOS server,
which probably places restrictions on the lengths of screennames and
the like.

However, it doesn't appear that Gaim checks the lengths of incoming
TLVs, and now that direct TCP connections to other clients are
supported, I think it's important to handle any outside data
carefully.  The attached patch changes the sprintf()s to snprintf()s.

Also, if this is not the best place for someone without CVS commit
access to send these sorts of small patches, just let me
know.

-- Wil

[Gaim-devel] Compiling GAim in Windows

[Brad <bra...@co...>]

I've tried and tried and tried, but I cannot figure out how to get GAim 
to compile in Windows.

Could someone post some specific, step-by-step, idiot proof 
instructions? Remember, we're Windows users! We're idiots! ./configure, 
make, make install blows our minds!

Re: [Gaim-devel] cvs compile error

[<lsc...@re...>]

/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:239: parse error
before `ch'

that looks like the only actually erroneous part. looks like your gnome install
has issues.
luke
-- 
-This email is made of 100% recycled electrons.

[Gaim-devel] cvs compile error

[Patrik B. <Ki...@gm...>]

I have problems compiling gaim cvs!

patrik@linux:~/Apps/gaim> make
make  all-recursive
make[1]: Wechsel in das Verzeichnis Verzeichnis »/home/patrik/Apps/gaim«
Making all in m4
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/m4«
make[2]: Für das Target »all« gibt es nichts zu tun.
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/m4«
Making all in sounds
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/sounds«
make[2]: Für das Target »all« gibt es nichts zu tun.
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/sounds«
Making all in plugins
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/plugins«
Making all in docklet
make[3]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/plugins/docklet«
source='docklet.c' object='docklet.lo' libtool=yes \
depfile='.deps/docklet.Plo' tmpdepfile='.deps/docklet.TPlo' \
depmode=gcc /bin/sh ../../depcomp \
/bin/sh ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I../.. -I../.. -I../../src -DVERSION=\"20020923\"
-DDATADIR=\"/home/patrik/garnome/share\"    -g -O2 -I/usr/local/include
-I/opt/include -I../..  -I/home/patrik/garnome/include/gtk-2.0
-I/home/patrik/garnome/lib/gtk-2.0/include
-I/home/patrik/garnome/include/atk-1.0
-I/home/patrik/garnome/include/pango-1.0 -I/usr/X11R6/include
-I/home/patrik/garnome/include -I/home/patrik/garnome/include/freetype2
-I/home/patrik/garnome/include/glib-2.0
-I/home/patrik/garnome/lib/glib-2.0/include   -DGTK_ENABLE_BROKEN
-I/home/patrik/garnome/include -I/opt/kde3/include/artsc -c -o
docklet.lo `test -f docklet.c || echo './'`docklet.c
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:32,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/usr/local/include/glib.h:153: warning: `G_STRUCT_OFFSET' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:160: warning: this
is the location of the previous definition
/usr/local/include/glib.h:155: warning: `G_STRUCT_MEMBER_P' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:162: warning: this
is the location of the previous definition
/usr/local/include/glib.h:240: warning: `G_GNUC_PRINTF' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:59: warning: this
is the location of the previous definition
/usr/local/include/glib.h:242: warning: `G_GNUC_SCANF' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:61: warning: this
is the location of the previous definition
/usr/local/include/glib.h:244: warning: `G_GNUC_FORMAT' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:63: warning: this
is the location of the previous definition
/usr/local/include/glib.h:246: warning: `G_GNUC_NORETURN' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:65: warning: this
is the location of the previous definition
/usr/local/include/glib.h:248: warning: `G_GNUC_CONST' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:67: warning: this
is the location of the previous definition
/usr/local/include/glib.h:250: warning: `G_GNUC_UNUSED' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:69: warning: this
is the location of the previous definition
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:32,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/usr/local/include/glib.h:491: warning: redefinition of `gssize'
/home/patrik/garnome/lib/glib-2.0/include/glibconfig.h:59: warning:
`gssize' previously declared here
/usr/local/include/glib.h:492: warning: redefinition of `gsize'
/home/patrik/garnome/lib/glib-2.0/include/glibconfig.h:60: warning:
`gsize' previously declared here
In file included from
/home/patrik/garnome/include/glib-2.0/glib-object.h:29,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-types.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-font.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:25,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/glib-2.0/gobject/gparamspecs.h:194: parse
error before `gunichar'
/home/patrik/garnome/include/glib-2.0/gobject/gparamspecs.h:194:
warning: no semicolon at end of struct or union
/home/patrik/garnome/include/glib-2.0/gobject/gparamspecs.h:327: parse
error before `gunichar'
In file included from
/home/patrik/garnome/include/glib-2.0/glib-object.h:31,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-types.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-font.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:25,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/glib-2.0/gobject/gsourceclosure.h:29: parse
error before `*'
In file included from
/home/patrik/garnome/include/glib-2.0/glib-object.h:36,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-types.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-font.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:25,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/glib-2.0/gobject/gvaluearray.h:66: parse
error before `GCompareDataFunc'
In file included from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:212:
parse error before `gunichar'
In file included from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:35,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/pango-1.0/pango/pango-layout.h:96: parse
error before `gunichar'
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkdrawable.h:7,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:33,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:133: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:148: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:159: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:167: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:263: parse
error before `GError'
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:294,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkdrawable.h:7,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:33,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf-loader.h:69:
parse error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf-loader.h:73:
parse error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf-loader.h:77:
parse error before `GError'
In file included from
/home/patrik/garnome/include/atk-1.0/atk/atkeditabletext.h:24,
                 from /home/patrik/garnome/include/atk-1.0/atk/atk.h:27,
                 from
/home/patrik/garnome/include/gtk-2.0/gtk/gtkaccessible.h:23,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:35,
                 from docklet.c:34:
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:178: parse error
before `gunichar'
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:178: warning: no
semicolon at end of struct or union
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:234: parse error
before `}'
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:249: parse error
before `atk_text_get_character_at_offset'
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:250: warning: data
definition has no type or storage class
In file included from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:64,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:111: parse error
before `gunichar'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:111: warning: no
semicolon at end of struct or union
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:114: parse error
before `}'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:154: parse error
before `gunichar'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:155: parse error
before `gtk_entry_get_invisible_char'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:155: warning: data
definition has no type or storage class
In file included from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:85,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtkimcontextsimple.h:50: parse
error before `gunichar'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkimcontextsimple.h:50:
warning: no semicolon at end of struct or union
/home/patrik/garnome/include/gtk-2.0/gtk/gtkimcontextsimple.h:53: parse
error before `:'
In file included from
/home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:128,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtkspinbutton.h:77: field
`entry' has incomplete type
In file included from
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextbuffer.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:135,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:106: parse error
before `gtk_text_iter_get_char'
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:106: warning:
data definition has no type or storage class
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:239: parse error
before `ch'
docklet.c: In function `docklet_update_icon':
docklet.c:194: warning: assignment makes pointer from integer without a
cast
docklet.c:197: warning: assignment makes pointer from integer without a
cast
docklet.c:200: warning: assignment makes pointer from integer without a
cast
docklet.c:204: warning: assignment makes pointer from integer without a
cast
docklet.c:207: warning: assignment makes pointer from integer without a
cast
docklet.c:210: warning: assignment makes pointer from integer without a
cast
docklet.c: At top level:
docklet.c:231: warning: `docklet_update_status' was declared implicitly
`extern' and later `static'
docklet.c:175: warning: previous declaration of `docklet_update_status'
docklet.c:231: warning: type mismatch with previous implicit declaration
docklet.c:175: warning: previous implicit declaration of
`docklet_update_status'
docklet.c:231: warning: `docklet_update_status' was previously
implicitly declared to return `int'
make[3]: *** [docklet.lo] Fehler 1
make[3]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/plugins/docklet«
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/plugins«
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim«
make: *** [all] Fehler 2
patrik@linux:~/Apps/gaim> 

Sorry for the long message, but I thought it would be better if i post
the whole log!
What have I done wrong?
-- 
Patrik Berger <Ki...@gm...>