At some point in time we in the desktop group discussed shipping bittorrent and a nice frontend in fedora core. Since more and more people start to use this as a standard way of distributing software (e.g. fedora core itself uses this) it really should be supported in a default desktop install, so that when you click on a torrent file in the browser something "nice" happens.
What are peoples opinions on this?
Another question is what frontend to use as a default. bittorrent itself ships with a wxPython based frontend (bittorrent-gui, availible with bittorrent in fedora extras). Another frontend is gnome-bt (http://gnome-bt.sourceforge.net/) which is designed more like a simple *.torrent mime handler rather than a full bittorrent app. Ubuntu defaults to this i think.
I packaged gnome-bt at: http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an uncontrollable guitar-strumming farmboy with a robot buddy named Sparky. She's a radical goth Valkyrie fleeing from a Satanic cult. They fight crime!
Alexander Larsson wrote:
At some point in time we in the desktop group discussed shipping bittorrent and a nice frontend in fedora core. Since more and more people start to use this as a standard way of distributing software (e.g. fedora core itself uses this) it really should be supported in a default desktop install, so that when you click on a torrent file in the browser something "nice" happens.
What are peoples opinions on this?
Another question is what frontend to use as a default. bittorrent itself ships with a wxPython based frontend (bittorrent-gui, availible with bittorrent in fedora extras). Another frontend is gnome-bt (http://gnome-bt.sourceforge.net/) which is designed more like a simple *.torrent mime handler rather than a full bittorrent app. Ubuntu defaults to this i think.
I packaged gnome-bt at: http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
Upstream bittorrent stopped using wxPython at 3.90; the current -gui package used in bittorrent 4.x is pygtk2-based and I don't see any advantages that gnome-bt has over it personally.
I think the only viable alternative would be azureus really, which is java-based.
Paul.
On Thu, Dec 15, 2005 at 04:12:03PM +0000, Paul Howarth wrote: | Alexander Larsson wrote: | >At some point in time we in the desktop group discussed shipping | >bittorrent and a nice frontend in fedora core. Since more and more | >people start to use this as a standard way of distributing software | >(e.g. fedora core itself uses this) it really should be supported in a | >default desktop install, so that when you click on a torrent file in the | >browser something "nice" happens. | > | >What are peoples opinions on this? | > | >Another question is what frontend to use as a default. bittorrent itself | >ships with a wxPython based frontend (bittorrent-gui, availible with | >bittorrent in fedora extras). Another frontend is gnome-bt | >(http://gnome-bt.sourceforge.net/) which is designed more like a simple | >*.torrent mime handler rather than a full bittorrent app. Ubuntu | >defaults to this i think. | > | >I packaged gnome-bt at: | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm | > | >I don't use bittorrent all that much. What do people think about these | >two frontends? Are there other interesting ones? | | Upstream bittorrent stopped using wxPython at 3.90; the current -gui | package used in bittorrent 4.x is pygtk2-based and I don't see any | advantages that gnome-bt has over it personally.
+1
If any bittorrent client is to slip into core, my vote is for the upstream default.
| I think the only viable alternative would be azureus really, which is | java-based.
Azureus is OK, but is a bit feature-bloated IMO for a pice of software that just needs to manage downloads (I mean, seriously, do people really need an IRC client built into their bittorrent client?). I think that the functionality of the standard upstream gui should satisfy all of our core needs.
luke
Luke Macken wrote:
On Thu, Dec 15, 2005 at 04:12:03PM +0000, Paul Howarth wrote: | Alexander Larsson wrote: | >At some point in time we in the desktop group discussed shipping | >bittorrent and a nice frontend in fedora core. Since more and more | >people start to use this as a standard way of distributing software | >(e.g. fedora core itself uses this) it really should be supported in a | >default desktop install, so that when you click on a torrent file in the | >browser something "nice" happens. | > | >What are peoples opinions on this? | > | >Another question is what frontend to use as a default. bittorrent itself | >ships with a wxPython based frontend (bittorrent-gui, availible with | >bittorrent in fedora extras). Another frontend is gnome-bt | >(http://gnome-bt.sourceforge.net/) which is designed more like a simple | >*.torrent mime handler rather than a full bittorrent app. Ubuntu | >defaults to this i think. | > | >I packaged gnome-bt at: | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm | > | >I don't use bittorrent all that much. What do people think about these | >two frontends? Are there other interesting ones? | | Upstream bittorrent stopped using wxPython at 3.90; the current -gui | package used in bittorrent 4.x is pygtk2-based and I don't see any | advantages that gnome-bt has over it personally.
+1
If any bittorrent client is to slip into core, my vote is for the upstream default.
| I think the only viable alternative would be azureus really, which is | java-based.
Azureus is OK, but is a bit feature-bloated IMO for a pice of software that just needs to manage downloads (I mean, seriously, do people really need an IRC client built into their bittorrent client?). I think that the functionality of the standard upstream gui should satisfy all of our core needs.
Agreed about the IRC client but does it allow bandwidth throttling, file priority selection (High, low, dont get), and UPnP router management? I haven't used it because azureus has satisfied all my needs just wondering what it provided and that rpm looks so far away. -mf
On Thu, 2005-12-15 at 10:45 -0600, Michael Favia wrote:
Luke Macken wrote:
If any bittorrent client is to slip into core, my vote is for the upstream default.
| I think the only viable alternative would be azureus really, which is | java-based.
Azureus is OK, but is a bit feature-bloated IMO for a pice of software that just needs to manage downloads (I mean, seriously, do people really need an IRC client built into their bittorrent client?). I think that the functionality of the standard upstream gui should satisfy all of our core needs.
Agreed about the IRC client but does it allow bandwidth throttling, file priority selection (High, low, dont get), and UPnP router management? I haven't used it because azureus has satisfied all my needs just wondering what it provided and that rpm looks so far away. -mf
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area. By all means though, get Azureus to work and find someone to package it into extras.
On 12/15/05, John (J5) Palmieri johnp@redhat.com wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area.
I think notification area item is going to be pretty important. Isn't the whole point of a bittorrent client to act as a peer even when the download is completed? If all people are doing is leeching and then turning off their own torrent nodes that sort of defeats the purpose of the peering concept. I think you'll definitely want to continue to inform the desktop user that the bittorrent node is still active and is uploading to other peers aftger the download is complete. I don't think you want that going on in the background without some visual que to remind people.
-jef
Jeff Spaleta wrote:
On 12/15/05, John (J5) Palmieri johnp@redhat.com wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area.
I think notification area item is going to be pretty important. Isn't the whole point of a bittorrent client to act as a peer even when the download is completed? If all people are doing is leeching and then turning off their own torrent nodes that sort of defeats the purpose of the peering concept. I think you'll definitely want to continue to inform the desktop user that the bittorrent node is still active and is uploading to other peers aftger the download is complete. I don't think you want that going on in the background without some visual que to remind people.
While i agree with j5 statemnt on simplicity i disagree that closing the torrent "defeats" the purpose. Even if individuals close the torrent after download they still supported the torrent throughout their download. (even if U/D ratios are biased). While it's only decent to wait till you have a 1:1 ratio imo it is perfectly acceptable to get what you need and mosey on if you'd like. A way to tell users about reaching 1:1 or any predefined ration in the systray would be appreciated though. -mf
On 12/15/05, Michael Favia michael.favia@insitesinc.com wrote:
Jeff Spaleta wrote: While i agree with j5 statemnt on simplicity i disagree that closing the torrent "defeats" the purpose. Even if individuals close the torrent after download they still supported the torrent throughout their download.
I have no problem letting users choose to stop their local bittorrent node whenever they wish. What I have a problem with is a default application that shutdowns the node activity at the end of downloads by default for everyone... pretending to be something like an http or ftp download client. The peer activity of the bittorrent process is important and i think it needs to be clear in the UI that uploads are happening and can continue to happen as long as the local bittorrent client stays alive.
I think its a bastardization of the bittorrent concept to have the default client in Core that people will reach for be so simple as to shutdown upload activity at the end of download activity without making an effort to educate the user that bittorent is a peer process and gives the user the choice to turn off the upload activity or leave it running. A notification area icon which uses the libnotify bubbly crap seems most appropriate to me.
-jef
On Thu, Dec 15, 2005 at 02:11:43PM -0500, Jeff Spaleta wrote: | On 12/15/05, Michael Favia michael.favia@insitesinc.com wrote: | > Jeff Spaleta wrote: | > While i agree with j5 statemnt on simplicity i disagree that closing the | > torrent "defeats" the purpose. Even if individuals close the torrent | > after download they still supported the torrent throughout their | > download. | | I have no problem letting users choose to stop their local bittorrent | node whenever they wish.
I think this is absolutely necessary. Bittorrent has the power to saturate a network real quick, and the last thing we want is a client that could potentially sit in the background behind peoples back un-noticed eating bandwidth just because we think keeping a 1:1 ratio is The Right Thing.
This is where a slick notification applet would come in handy.
| What I have a problem with is a default | application that shutdowns the node activity at the end of downloads | by default for everyone... pretending to be something like an http or | ftp download client. The peer activity of the bittorrent process is | important and i think it needs to be clear in the UI that uploads are | happening and can continue to happen as long as the local bittorrent | client stays alive.
The default gui client has sane post-completion seeding settings, so it doesn't end the seed when the download is finished.
| I think its a bastardization of the bittorrent concept to have the | default client in Core that people will reach for be so simple as to | shutdown upload activity at the end of download activity without | making an effort to educate the user that bittorent is a peer process | and gives the user the choice to turn off the upload activity or leave | it running. A notification area icon which uses the libnotify bubbly | crap seems most appropriate to me.
I agree.
luke
On Thu, 2005-12-15 at 12:45 -0600, Michael Favia wrote:
While i agree with j5 statemnt on simplicity i disagree that closing the torrent "defeats" the purpose. Even if individuals close the torrent after download they still supported the torrent throughout their download. (even if U/D ratios are biased). While it's only decent to wait till you have a 1:1 ratio imo it is perfectly acceptable to get what you need and mosey on if you'd like.
Yup - a lot of users have really restricted upload. I use bt on a headless box - through a torrent file into ~/torrent/active/ and it goes - I try to leave them in there for at least a week or so (though never more than 3 at once) because I can, it doesn't bother me to seed - and I know some people have really limited upload and it isn't reasonable to expect everyone to seed until 1:1
Those who have bandwidth can seed beyond 1:1 to compensate.
You misinterpreted what I was saying. Gaim is the best example here. Start it up and an icon appears in the notification area which is persistent until you exit gaim. But that is just a thought and not indicative of what we are trying to choose here, which is out of teh existing GUI's which one do we pick. I'm just saying as long as the client gives feedback and is launched when clicking on a torrent file, pick the simplest one out there as the default.
On Thu, 2005-12-15 at 13:33 -0500, Jeff Spaleta wrote:
On 12/15/05, John (J5) Palmieri johnp@redhat.com wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area.
I think notification area item is going to be pretty important. Isn't the whole point of a bittorrent client to act as a peer even when the download is completed? If all people are doing is leeching and then turning off their own torrent nodes that sort of defeats the purpose of the peering concept. I think you'll definitely want to continue to inform the desktop user that the bittorrent node is still active and is uploading to other peers aftger the download is complete. I don't think you want that going on in the background without some visual que to remind people.
-jef
Jeff Spaleta wrote:
On 12/15/05, John (J5) Palmieri johnp@redhat.com wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area.
I think notification area item is going to be pretty important. Isn't the whole point of a bittorrent client to act as a peer even when the download is completed? If all people are doing is leeching and then turning off their own torrent nodes that sort of defeats the purpose of the peering concept. I think you'll definitely want to continue to inform the desktop user that the bittorrent node is still active and is uploading to other peers aftger the download is complete. I don't think you want that going on in the background without some visual que to remind people.
-jef
The biggest problem with this entire idea is that it wont work for users by default, because our default security configuration will block incoming connections, and more users these days are behind NAT.
Warren Togami wtogami@redhat.com
On Fri, 2005-12-16 at 19:57 -0500, Warren Togami wrote:
The biggest problem with this entire idea is that it wont work for users by default, because our default security configuration will block incoming connections, and more users these days are behind NAT.
Users behind NAT isn't a Fedora problem. They need to port forward the BT ports - but that can go on something like fedorafaq.org (or whatever it is).
Firewall is a problem. A nice gui like firestarter (not necessarily firestarter, but something like it) for configuring the Fedora Firewall would be nice - with common app/port selections so users don't necessarily have to care what port ranges are used for what (unless they want to meddle with the defaults)
until I decided to go with Linksys for my router, firestarter is what I used for NAT - it has a really nice interface for controlling what ports are allowed in etc.
On Sat, December 17, 2005 3:53 am, Michael A. Peters said:
Users behind NAT isn't a Fedora problem. They need to port forward the BT ports - but that can go on something like fedorafaq.org (or whatever it is).
Well Fedora could help the situation by making sure its default bt client supports UPnP so that a compliant nat router (like most linksys) will automatically be configured without the user needing to deal with it at all.
Firewall is a problem. A nice gui like firestarter (not necessarily firestarter, but something like it) for configuring the Fedora Firewall would be nice - with common app/port selections so users don't necessarily have to care what port ranges are used for what (unless they want to meddle with the defaults)
until I decided to go with Linksys for my router, firestarter is what I used for NAT - it has a really nice interface for controlling what ports are allowed in etc.
It would be nice if the user just had to answer a simple question like "Would you like to open the ports needed for BT in your firewall configuration?".
The same problem exists when trying to configure many other network apps too. It would be great to have a general framework for apps to request open ports from the firewall and have the user just get a popup so that she can agree or cancel. Perhaps this could all be done over dbus? Does something like this already exist?
Sean
John (J5) Palmieri wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area. By all means though, get Azureus to work and find someone to package it into extras.
I don't mean to get into "my favorite client is X" debate, but if we're picking something for core, I'd argue for picking a client that people really love.[1] I've never used Azureus, but by that reasoning, since Azureus is regularly on sf.net's most downloaded/highest activity lists, it's a good choice. The "safe but boring" default client is a bad choice.
[1] http://headrush.typepad.com/creating_passionate_users/2005/12/being_brave_is...
On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote:
John (J5) Palmieri wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area. By all means though, get Azureus to work and find someone to package it into extras.
I don't mean to get into "my favorite client is X" debate, but if we're picking something for core, I'd argue for picking a client that people really love.[1] I've never used Azureus, but by that reasoning, since Azureus is regularly on sf.net's most downloaded/highest activity lists, it's a good choice. The "safe but boring" default client is a bad choice.
[1] http://headrush.typepad.com/creating_passionate_users/2005/12/being_brave_is...
And what happens when app XYZ becomes the flavor of the month? Remember, not having it as the default doesn't mean it is not there.
From the responses on this thread I would really encourage someone to
package Azureus up for extras because people do seem to love it. I can imagine torrents becoming just like regular download. Oh how I would hate it if every time I went to download a new tarball a huge management window would pop up. All I would want is something to tell me it is downloading and notify me when it is finished.
John (J5) Palmieri wrote:
On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote:
John (J5) Palmieri wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area. By all means though, get Azureus to work and find someone to package it into extras.
I don't mean to get into "my favorite client is X" debate, but if we're picking something for core, I'd argue for picking a client that people really love.[1] I've never used Azureus, but by that reasoning, since Azureus is regularly on sf.net's most downloaded/highest activity lists, it's a good choice. The "safe but boring" default client is a bad choice.
[1] http://headrush.typepad.com/creating_passionate_users/2005/12/being_brave_is...
And what happens when app XYZ becomes the flavor of the month? Remember, not having it as the default doesn't mean it is not there.
From the responses on this thread I would really encourage someone to
package Azureus up for extras because people do seem to love it. I can imagine torrents becoming just like regular download. Oh how I would hate it if every time I went to download a new tarball a huge management window would pop up. All I would want is something to tell me it is downloading and notify me when it is finished.
To that end i would also appreciate it if would configure UPnP for me and allow me to throttle the bandwidth or select files to exclude (especially in distro downloads). But then you end up with azureus minus the IRC client don't you? -mf
On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote:
John (J5) Palmieri wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area. By all means though, get Azureus to work and find someone to package it into extras.
I don't mean to get into "my favorite client is X" debate, but if we're picking something for core, I'd argue for picking a client that people really love.[1] I've never used Azureus, but by that reasoning, since Azureus is regularly on sf.net's most downloaded/highest activity lists, it's a good choice. The "safe but boring" default client is a bad choice.
Fedora focuses on Gnome. For UI consistency - a gnome client is best imho. A non gnome gtk client is acceptable.
Java - I'm not a big fan. I've never tried Azureus - but the only operating system I've ever used where gui java apps look even halfway acceptable is OS X.
On 12/16/2005 11:27 PM, Michael A. Peters wrote:
On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote:
John (J5) Palmieri wrote:
Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area. By all means though, get Azureus to work and find someone to package it into extras.
I don't mean to get into "my favorite client is X" debate, but if we're picking something for core, I'd argue for picking a client that people really love.[1] I've never used Azureus, but by that reasoning, since Azureus is regularly on sf.net's most downloaded/highest activity lists, it's a good choice. The "safe but boring" default client is a bad choice.
Fedora focuses on Gnome. For UI consistency - a gnome client is best imho. A non gnome gtk client is acceptable.
Funny that Azureus uses SWT toolkit, which in turn uses GTK :-)
Java - I'm not a big fan. I've never tried Azureus - but the only operating system I've ever used where gui java apps look even halfway acceptable is OS X.
See Eclipse (SWT as well).
Granted, I'm not a big fan of many Java GUI apps -- people go too wild with "app has to look their way", which ends up in too many apps looking different :( (And I'm a Java developer myself.)
Regards, Dariusz
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On Fri, 2005-12-16 at 23:39 +0000, Dariusz J. Garbowski wrote:
Funny that Azureus uses SWT toolkit, which in turn uses GTK :-)
OK. There's a good chance I don't know what I'm talking about. I don't think I've ever used a Java gui app that uses gtk.
If it uses gtk - that's a definite +
Azureus is OK, but is a bit feature-bloated IMO for a pice of software that just needs to manage downloads (I mean, seriously, do people really need an IRC client built into their bittorrent client?).
But where besides irc do you go to find out where to get the 0-day Warez and pr0n..
err
nevermind.
just forget I said anything. :)
-sv
Alexander Larsson wrote:
At some point in time we in the desktop group discussed shipping bittorrent and a nice frontend in fedora core. Since more and more people start to use this as a standard way of distributing software (e.g. fedora core itself uses this) it really should be supported in a default desktop install, so that when you click on a torrent file in the browser something "nice" happens.
What are peoples opinions on this?
Another question is what frontend to use as a default. bittorrent itself ships with a wxPython based frontend (bittorrent-gui, availible with bittorrent in fedora extras). Another frontend is gnome-bt (http://gnome-bt.sourceforge.net/) which is designed more like a simple *.torrent mime handler rather than a full bittorrent app. Ubuntu defaults to this i think.
I packaged gnome-bt at: http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
Java haters unite but i find the azureus bt client to be useful and full featured. It handles UPnP through the router and allows me to set importance values on individual files in a torrent as well as manage full bandwidth throttling. Using these features i only have to download CD's 1 and 2 of a 4 cd distro torrent if id like and i dont have to swamp the network to do it. I havent tried it for compliance ontop of the fedora "free" java stack but it runs quickly on my old clunker on the sun JVM. Take a look at:
Err, Azureus is nice, I use it myself, but its squarely a super-ultra-mega power user application, I'd hesitate to set it up as a Fedora default.
On Thu, December 15, 2005 11:09 am, Alexander Larsson said:
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
Azureus is really the best. Just did a quick google to see if gcj 4.1 can compile it, and sure enough Slashdot says it works, so it must be true ;)
Cheers, Sean
Alexander Larsson (alexl@redhat.com) said:
Another question is what frontend to use as a default. bittorrent itself ships with a wxPython based frontend (bittorrent-gui, availible with bittorrent in fedora extras). Another frontend is gnome-bt (http://gnome-bt.sourceforge.net/) which is designed more like a simple *.torrent mime handler rather than a full bittorrent app. Ubuntu defaults to this i think.
I packaged gnome-bt at: http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :)
Bill
On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote:
Alexander Larsson (alexl@redhat.com) said:
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :)
One issue with gnome-bt is that it depends on the bittorrent package, and the bittorrent package already includes the default gui app, so unless you do some creative packaging you would get two bittorrent UIs with gnome-bt as the default.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a notorious white trash filmmaker on the hunt for the last specimen of a great and near-mythical creature. She's a psychotic gold-digging wrestler from the wrong side of the tracks. They fight crime!
Alexander Larsson wrote :
On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote:
Alexander Larsson (alexl@redhat.com) said:
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :)
One issue with gnome-bt is that it depends on the bittorrent package, and the bittorrent package already includes the default gui app, so unless you do some creative packaging you would get two bittorrent UIs with gnome-bt as the default.
The current Extras bittorent package already splits the GUI into a sub-package called "bittorrent-gui", so as long as gnome-bt only requires what is contained in "bittorrent", it should work out fine.
Matthias
Matthias Saou wrote:
Alexander Larsson wrote :
On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote:
Alexander Larsson (alexl@redhat.com) said:
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :)
One issue with gnome-bt is that it depends on the bittorrent package, and the bittorrent package already includes the default gui app, so unless you do some creative packaging you would get two bittorrent UIs with gnome-bt as the default.
The current Extras bittorent package already splits the GUI into a sub-package called "bittorrent-gui", so as long as gnome-bt only requires what is contained in "bittorrent", it should work out fine.
Probably not actually. Extras has bittorrent 4.2.0 and gnome-bt doesn't work with anything newer than 3.4.2; at least not last time I tried it.
http://sourceforge.net/tracker/index.php?func=detail&aid=1189957&gro...
Paul.
On Fri, 2005-12-16 at 11:08 +0000, Paul Howarth wrote:
Matthias Saou wrote:
Alexander Larsson wrote :
On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote:
Alexander Larsson (alexl@redhat.com) said:
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :)
One issue with gnome-bt is that it depends on the bittorrent package, and the bittorrent package already includes the default gui app, so unless you do some creative packaging you would get two bittorrent UIs with gnome-bt as the default.
The current Extras bittorent package already splits the GUI into a sub-package called "bittorrent-gui", so as long as gnome-bt only requires what is contained in "bittorrent", it should work out fine.
Probably not actually. Extras has bittorrent 4.2.0 and gnome-bt doesn't work with anything newer than 3.4.2; at least not last time I tried it.
http://sourceforge.net/tracker/index.php?func=detail&aid=1189957&gro...
I didn't really do much testing, but http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm seemed to work fine with current bittorrent from extras.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an ungodly chivalrous filmmaker plagued by the memory of his family's brutal murder. She's a sharp-shooting tomboy stripper from aristocratic European stock. They fight crime!
On Fri, 2005-12-16 at 12:01 +0100, Matthias Saou wrote:
Alexander Larsson wrote :
On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote:
Alexander Larsson (alexl@redhat.com) said:
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :)
One issue with gnome-bt is that it depends on the bittorrent package, and the bittorrent package already includes the default gui app, so unless you do some creative packaging you would get two bittorrent UIs with gnome-bt as the default.
The current Extras bittorent package already splits the GUI into a sub-package called "bittorrent-gui", so as long as gnome-bt only requires what is contained in "bittorrent", it should work out fine.
It might not have to be in the default install, but it has to be in core, as they build from the same SRPM.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly misogynist rock star with a robot buddy named Sparky. She's an elegant belly-dancing journalist from aristocratic European stock. They fight crime!
Alexander Larsson (alexl@redhat.com) said:
On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote:
Alexander Larsson (alexl@redhat.com) said:
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :)
One issue with gnome-bt is that it depends on the bittorrent package, and the bittorrent package already includes the default gui app, so unless you do some creative packaging you would get two bittorrent UIs with gnome-bt as the default.
True. It can be packaged around, or just ignored as a problem. It was just that it seemed to me that having gnome-bt as something that would pop up after hitting a torrent file in nautilus, firefox, etc. would be a better solution than the standalone client.
Bill
On Sat, 2005-12-17 at 02:08 -0500, Bill Nottingham wrote:
Alexander Larsson (alexl@redhat.com) said: True. It can be packaged around, or just ignored as a problem. It was just that it seemed to me that having gnome-bt as something that would pop up after hitting a torrent file in nautilus, firefox, etc. would be a better solution than the standalone client.
I think the standard ui client looks fine for "just clicked on a .torrent file" actually. I'm not sure gnome-bt is better for this.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an oversexed flyboy jungle king on the hunt for the last specimen of a great and near-mythical creature. She's a cold-hearted snooty politician with a flame-thrower. They fight crime!
On Mon, December 19, 2005 3:00 am, Alexander Larsson said:
I think the standard ui client looks fine for "just clicked on a .torrent file" actually. I'm not sure gnome-bt is better for this.
Yeah, the gui looks fine. As for real ease-of-use though it would be nicer if the Fedora client actually supported UPnP.
Sean
P.S. Just installed the bittorrent-gui to take a look at it and the first thing it says when you start it is "Newer version available, would you like to download it now" which is a bit annoying for a package that should only be updated via rpm.
Sean wrote:
On Mon, December 19, 2005 3:00 am, Alexander Larsson said:
I think the standard ui client looks fine for "just clicked on a .torrent file" actually. I'm not sure gnome-bt is better for this.
Yeah, the gui looks fine. As for real ease-of-use though it would be nicer if the Fedora client actually supported UPnP.
Sean
P.S. Just installed the bittorrent-gui to take a look at it and the first thing it says when you start it is "Newer version available, would you like to download it now" which is a bit annoying for a package that should only be updated via rpm.
I've pushed an update to 4.2.2 earlier today. I'm not sure about disabling the "updated version" check. On the one hand people should only be updating the package using RPM, but on the other hand the alert will let them know that a new version is available, and that might prompt them to run "yum update" if they don't have automatic updates turned on.
Paul.
On Mon, 2005-12-19 at 16:52 +0000, Paul Howarth wrote:
[...] but on the other hand the alert will let them know that a new version is available, and that might prompt them to run "yum update" if they don't have automatic updates turned on.
But on the yet other hand the update may not be available in the yum repository yet (and may not even be there six months later if it's not an important update), which will simply frustrate them.
roozbeh
Roozbeh Pournader wrote:
On Mon, 2005-12-19 at 16:52 +0000, Paul Howarth wrote:
[...] but on the other hand the alert will let them know that a new version is available, and that might prompt them to run "yum update" if they don't have automatic updates turned on.
But on the yet other hand the update may not be available in the yum repository yet (and may not even be there six months later if it's not an important update), which will simply frustrate them.
Well, as the maintainer of the bittorrent package, at least whilst it's in Extras, I can assure you that updates won't take anything like 6 months to turn up ;-)
Paul.
On Mon, 2005-12-19 at 17:22 +0000, Paul Howarth wrote:
But on the yet other hand the update may not be available in the yum repository yet (and may not even be there six months later if it's not an important update), which will simply frustrate them.
Well, as the maintainer of the bittorrent package, at least whilst it's in Extras, I can assure you that updates won't take anything like 6 months to turn up ;-)
But not if it's taken into Core. The update may simply be not important enough, and the current practice of Core is something like "if it's not SECURITY, convince the packager that the update is needed for FC$stable" or you won't get an update.
roozbeh
Roozbeh Pournader wrote:
On Mon, 2005-12-19 at 17:22 +0000, Paul Howarth wrote:
But on the yet other hand the update may not be available in the yum repository yet (and may not even be there six months later if it's not an important update), which will simply frustrate them.
Well, as the maintainer of the bittorrent package, at least whilst it's in Extras, I can assure you that updates won't take anything like 6 months to turn up ;-)
But not if it's taken into Core. The update may simply be not important enough, and the current practice of Core is something like "if it's not SECURITY, convince the packager that the update is needed for FC$stable" or you won't get an update.
If bittorrent was in Core, it would be quite reasonable for the packager to take a different view of whether or not to leave the update notification enabled, I agree. But for the time being, it's in Extras and I'm inclined to leave it the way it is.
Paul.
On Mon, December 19, 2005 11:52 am, Paul Howarth said:
I've pushed an update to 4.2.2 earlier today. I'm not sure about disabling the "updated version" check. On the one hand people should only be updating the package using RPM, but on the other hand the alert will let them know that a new version is available, and that might prompt them to run "yum update" if they don't have automatic updates turned on.
Great. I must have just upgraded a bit before your push.
As for the auto-update feature, the user already has utilities that notify them when an update is available; why a special update notice for this one little app? Also, a naive user might not understand that they should wait for the update to appear via their normal update process. Also, an admin might turn off the regular auto-updating for users and not know he has to do something special to shut off this one app.
All in all, there are a lot of reasons that having a separate update notification available for this app.
Cheers, Sean
Sean wrote:
On Mon, December 19, 2005 11:52 am, Paul Howarth said:
I've pushed an update to 4.2.2 earlier today. I'm not sure about disabling the "updated version" check. On the one hand people should only be updating the package using RPM, but on the other hand the alert will let them know that a new version is available, and that might prompt them to run "yum update" if they don't have automatic updates turned on.
Great. I must have just upgraded a bit before your push.
Which version of bittorrent are you using? Looking at the code, it looks to me that the update-checking code is only enabled for Windows and OSX unless the DEBUG flag is set.
As for the auto-update feature, the user already has utilities that notify them when an update is available; why a special update notice for this one little app? Also, a naive user might not understand that they should wait for the update to appear via their normal update process. Also, an admin might turn off the regular auto-updating for users and not know he has to do something special to shut off this one app.
All in all, there are a lot of reasons that having a separate update notification available for this app.
I now share the view that the new version check should be disabled. However, I've so far been unable to provoke the client into telling me about a new version, even though I've got an old one installed, so it's difficult to test any patch I make (which will certainly need testing since I'm not a python programmer).
Paul.
On Tue, December 20, 2005 7:30 am, Paul Howarth said:
Hi Paul,
Which version of bittorrent are you using? Looking at the code, it looks to me that the update-checking code is only enabled for Windows and OSX unless the DEBUG flag is set.
I haven't looked at the code but it is definitely coming up with an update notification. I'm using bittorrent-4.2.1-1.fc5 and it reports that 4.2.2 is available.
I now share the view that the new version check should be disabled. However, I've so far been unable to provoke the client into telling me about a new version, even though I've got an old one installed, so it's difficult to test any patch I make (which will certainly need testing since I'm not a python programmer).
If you remove or rename your ~/.bittorrent directory, the notification should pop up the next time you start the client.
Sean
Sean wrote:
On Tue, December 20, 2005 7:30 am, Paul Howarth said:
Hi Paul,
Which version of bittorrent are you using? Looking at the code, it looks to me that the update-checking code is only enabled for Windows and OSX unless the DEBUG flag is set.
I haven't looked at the code but it is definitely coming up with an update notification. I'm using bittorrent-4.2.1-1.fc5 and it reports that 4.2.2 is available.
I now share the view that the new version check should be disabled. However, I've so far been unable to provoke the client into telling me about a new version, even though I've got an old one installed, so it's difficult to test any patch I make (which will certainly need testing since I'm not a python programmer).
If you remove or rename your ~/.bittorrent directory, the notification should pop up the next time you start the client.
Indeed it does. I've done a quick patch, which seems to fix it for me at least. We'll see when 4.2.3 comes out ;-)
Paul.
On Tue, 2005-12-20 at 15:21 -0500, Alan Cox wrote:
On Mon, Dec 19, 2005 at 09:00:47AM +0100, Alexander Larsson wrote:
I think the standard ui client looks fine for "just clicked on a .torrent file" actually. I'm not sure gnome-bt is better for this.
Does the standard UI include accessibility hooks ?
It uses Gtk+, and thus would have the standard atk support, but I don't know if it does anything special about a11y.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an impetuous soccer-playing cop with a secret. She's a tortured gold-digging wrestler on the trail of a serial killer. They fight crime!
Hey, I just noticed this turn up in Debian:
http://www.ruinedsoft.com/freeloader/
I haven't actually tried it yet, but its a GNOME download manager that supports torrents and appears to have a nice simple clean UI.
On 12/15/05, Alexander Larsson alexl@redhat.com wrote:
At some point in time we in the desktop group discussed shipping bittorrent and a nice frontend in fedora core. Since more and more people start to use this as a standard way of distributing software (e.g. fedora core itself uses this) it really should be supported in a default desktop install, so that when you click on a torrent file in the browser something "nice" happens.
What are peoples opinions on this?
Another question is what frontend to use as a default. bittorrent itself ships with a wxPython based frontend (bittorrent-gui, availible with bittorrent in fedora extras). Another frontend is gnome-bt (http://gnome-bt.sourceforge.net/) which is designed more like a simple *.torrent mime handler rather than a full bittorrent app. Ubuntu defaults to this i think.
I packaged gnome-bt at: http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm
I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones?
If you are going to package a client with the OS make it bittorrent-gui
- I actually used this for a while because azureus is kind of a resource hog sometimes. Azureus is working a bit better now since the latest update so I switched back. For simplicity bittorrent-gui works fine and it also manages the upload ratio quite well actually. If you feel the need to do so you can actually tell bittorrent-gui to keep seeding any of the files indefinately if you are trying to get your share ratio up. At one point I had 5 items set to seed indefinately while I was downloading a few others. It is nowhere near as powerful as azureus but it is a decent simple program. Since the 4.2 update bittorrent-gui became even more customizable, although people have to realize they need to right-click on the torrent to access some of the extra features like seed indefinately.
Sincerely,
-- Gerald Thompson geraldlt@gmail.com www.gltechsolutions.com
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Alexander Larsson -
Bill Nottingham -
Callum Lerwick -
Dariusz J. Garbowski -
Gerald Thompson -
Jack Tanner -
Jef Spaleta -
John (J5) Palmieri -
Luke Macken -
Matthias Saou -
Michael A. Peters -
Michael Favia -
Paul A Houle -
Paul Howarth -
Roozbeh Pournader -
Sean -
seth vidal -
Warren Togami