I think it's unnecessarily troublesome to adjust the number or order of downloads and uploads by using the Configuration and Queue Manager. These features can be intuitively integrated into the main interface.

• To control how many torrents should download concurrently, the user just needs to Start, Stop, or Enqueue a download. Note that when a started torrent is Enqueued, it should enter the Queued state, contrary to the current behavior (because currently the number in Configuration controls whether the torrent in queue will start). Whenever any of these actions is performed by the user (not automatically by KTorrent, e.g. when a download is finished), the maximum number of concurrent downloads should be updated to be the total number of torrents in the "started" state (including Downloading and Stalled). Similar for uploading torrents.
  
  This allows the number of concurrent downloads or uploads be adjusted quickly, as well as starting or stop-and-queuing a download at the same time, and gets rid of the annoying "Cannot start more than n downloads, go to Settings -> Configure KTorrent ..." dialog.
  
• To control the queue order, there can be buttons in the toolbar, or actions in the context menu to move selected queued torrents up/down the queue. There should also be a column in the list view showing the queue order of torrents. When the torrents are sorted by queue order, the user can also drag and drop torrents in the listview to change their queue order. This might be hard to handle when mouse dragging also multi-selects torrents. But it should be still possible by treating a drag when there are is no selection as multiselection, and when there is a selection, as changing queue order. Or there can be an mechanism such as only Shift-modified drag-and-drop will change queue order.
  
  This will mostly remove the need to open Queue Manager. It's quicker, and allows you to see the queue order quickly as well. I think Azureus also changes queue order with this method.

hagabaka wrote:I think it's unnecessarily troublesome to adjust the number or order of downloads and uploads by using the Configuration and Queue Manager. These features can be intuitively integrated into the main interface.

[list][*]To control how many torrents should download concurrently, the user just needs to Start, Stop, or Enqueue a download. Note that when a started torrent is Enqueued, it should enter the Queued state, contrary to the current behavior (because currently the number in Configuration controls whether the torrent in queue will start). Whenever any of these actions is performed by the user (not automatically by KTorrent, e.g. when a download is finished), the maximum number of concurrent downloads should be updated to be the total number of torrents in the "started" state (including Downloading and Stalled). Similar for uploading torrents.

This allows the number of concurrent downloads or uploads be adjusted quickly, as well as starting or stop-and-queuing a download at the same time, and gets rid of the annoying "Cannot start more than n downloads, go to Settings -> Configure KTorrent ..." dialog.

You're right, if a user manually starts a torrent, (s)he wants it to start, and does not want to be fiddling around with the limits in the settings dialog.

But I don't know if we should do this by increasing the limit, that could be confusing. And we would have people posting on the forums about how KT just starts changing the limits they have set.

[*]To control the queue order, there can be buttons in the toolbar, or actions in the context menu to move selected queued torrents up/down the queue. There should also be a column in the list view showing the queue order of torrents. When the torrents are sorted by queue order, the user can also drag and drop torrents in the listview to change their queue order. This might be hard to handle when mouse dragging also multi-selects torrents. But it should be still possible by treating a drag when there are is no selection as multiselection, and when there is a selection, as changing queue order. Or there can be an mechanism such as only Shift-modified drag-and-drop will change queue order.
]

Seeing that we are busy adding groups, which has resulted in a switch to a KDevelop style IDEAl GUI (currently under development), this is not gonna go.

There will be only one view showing the currently selected group, a group can contain both seeds and downloads at the same time.

However, we could ditch the dialog on the QM and place it's functionality in a tab at the bottom or on the sides, so you don't need to open a special dialog to edit the order.

But we will decide on that when the new GUI is fully functioning.

Thanks for your reply.

George wrote:But I don't know if we should do this by increasing the limit, that could be confusing. And we would have people posting on the forums about how KT just starts changing the limits they have set.

You're right; people not knowing about this method of controlling the limit will be confused. However, there could be a way to let them know, and choose whether to use this. In the Configuration dialog where the limits are set, there can be a checkbox toggling this feature, and the label could be something like "Control this limit in the main UI". A tooltip could clarify what that means. I think for users whose connection performance and usage vary a lot, this would be more useful than the current behavior.

George wrote:Seeing that we are busy adding groups, which has resulted in a switch to a KDevelop style IDEAl GUI (currently under development), this is not gonna go.

There will be only one view showing the currently selected group, a group can contain both seeds and downloads at the same time.

First, regardless of this feature request, I think it's a bad idea to mix uploading and downloading torrents in tabs. This would make it inconvenient to stop all downloading torrents or uploading torrents, and arrange the view to e.g. sort all the uploading torrents by the number of peers, for example. If there is a better place to discuss this change, I would appreciate it if you could let me know.

If the downloading and uploading torrents could be displayed separately in the new UI, and there could be separate tabs listing all the downloading and all the uploading torrents (like the current tabs, which are useful), then the method of controlling queue order in my feature request can still be implemented.

hagabaka wrote:Thanks for your reply.

You're right; people not knowing about this method of controlling the limit will be confused. However, there could be a way to let them know, and choose whether to use this. In the Configuration dialog where the limits are set, there can be a checkbox toggling this feature, and the label could be something like "Control this limit in the main UI". A tooltip could clarify what that means. I think for users whose connection performance and usage vary a lot, this would be more useful than the current behavior.

Maybe it is easier to just let the limit only apply for the torrents controlled by the queue manager.

First, regardless of this feature request, I think it's a bad idea to mix uploading and downloading torrents in tabs. This would make it inconvenient to stop all downloading torrents or uploading torrents, and arrange the view to e.g. sort all the uploading torrents by the number of peers, for example. If there is a better place to discuss this change, I would appreciate it if you could let me know.

If the downloading and uploading torrents could be displayed separately in the new UI, and there could be separate tabs listing all the downloading and all the uploading torrents (like the current tabs, which are useful), then the method of controlling queue order in my feature request can still be implemented.

We will have 3 fixed groups for downloads, uploads and all torrents. So this is not a problem.

George wrote:However, we could ditch the dialog on the QM and place it's functionality in a tab at the bottom or on the sides, so you don't need to open a special dialog to edit the order.

I would vote for that. Having the QM as a part of the normal GUI would make it cleaner to interact with the controls, and thus easier to use. (less windows (where it's usefull) is always better in my view)

But we will decide on that when the new GUI is fully functioning.

Gees this one is already so slik... you're making KTorrent too much fun.

George wrote:Maybe it is easier to just let the limit only apply for the torrents controlled by the queue manager.

Actually I'm not sure what "QM controlled" means. I only know that my torrents become "User controlled" after I start/stop them, and "QM controlled" after I queue them. (This is another reason why I think Queue Manager makes the UI too complicated.) So does "QM controlled" basically mean any torrent the user last used the "Queue" action on, and newly added torrents? Then it's similar to my requested behavior: only torrents in the queue will ever be automatically started. If a user does not want a torrent to be automatically started, [s]he can put it into Stopped state, like [s]he can now.

hagabaka wrote:

George wrote:Maybe it is easier to just let the limit only apply for the torrents controlled by the queue manager.

Actually I'm not sure what "QM controlled" means. I only know that my torrents become "User controlled" after I start/stop them, and "QM controlled" after I queue them. (This is another reason why I think Queue Manager makes the UI too complicated.) So does "QM controlled" basically mean any torrent the user last used the "Queue" action on, and newly added torrents? Then it's similar to my requested behavior: only torrents in the queue will ever be automatically started. If a user does not want a torrent to be automatically started, [s]he can put it into Stopped state, like [s]he can now.

All torrents are by default QM controlled, which means that the QM decides to start and stop them. It decides based on the limit and the priority of each torrent which to run.

So that torrents get stopped when they reach their max share ratio and other torrents will be started. Or when a torrent is stopped another one can run. Or when a download is finished, a queued one can be started.

The moment you decide to manually start or stop a torrent, we obviously cannot let the QM control it anymore. It could result in situations where the user starts a torrent and then the QM stops it again.