Menu
▾
▴
pidgin-devel
|
From: Brian F. <bdf...@un...> - 2002-10-01 03:50:05
|
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. |
|
From: William T. M. <wt...@du...> - 2002-10-01 05:52:08
|
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 |
|
From: Christian H. <ch...@gn...> - 2002-10-01 06:01:36
|
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. |
|
From: Nathan W. <fac...@fa...> - 2002-10-01 06:25:40
|
> 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 |
|
From: Luke S. <lsc...@gm...> - 2002-10-01 11:33:12
|
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. |
|
From: Brian F. <bdf...@un...> - 2002-10-01 12:47:44
|
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/ |
|
From: Luke S. <lsc...@gm...> - 2002-10-01 16:12:26
|
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. |
|
From: Rob F. <ro...@ma...> - 2002-10-01 08:36:45
|
> > 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. |
|
From: Sean E. <se...@se...> - 2002-10-09 21:00:54
|
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. |
|
From: Robert M. <rob...@de...> - 2002-10-02 02:41:33
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X