edit Cross posted to KTorrent's own forums: New 4.2 Ktorrent GUI = fail

First:

I want to apologize for the Subject line. I'm not trying to be obnoxious, critical of anyone, mean or troll like.

I do want the ktorrent developers plus anyone else interested in ktorrent usability to sit up and take notice. Hence the somewhat attention getting nature of the Subject line.

This is going to be a long post. Get a large mug of your favorite beverage, bowl of assorted snacks and comfy chair. You have been warned.

Some Background:

I'm a long time user of KDE (from KDE 1.x) running under the Gentoo distribution (from Gentoo 1.x). I've used ktorrent since it was first available. If you're familiar with how the Gentoo distribution works, it should be relevant to you that I run a 'world' update every 2-3 weeks. You can find some of my posts in the Gentoo forums by using Google and the search terms "site:forums.gentoo.org dufeu" {without quotes of course}. I consider myself to be a fairly competent user with a decent grasp of what's going on.

With the recent upgrade of KDE from 4.8.0 to 4.8.1, I also received the upgrade of ktorrent to 4.2. I've lived with the upgrade now for about 2 weeks in an effort to make sure I understand the ktorrent GUI changes.

The remainder of this post will discuss various issues I believe I've identified in terms of usability.

More Background: Usage

For the immediate few paragraphs, I'm going to define 'active' torrents as those torrents which ktorrent currently lists. 'Inactive' torrents are those torrents which have completed {or been killed and removed} but for which the torrent files themselves are still retained in a 'completed torrents' directory.

The 'completed torrents' directory is never cleared. This is an aid to not repeat any given torrent download. Point of info: The 'completed torrents' directory currently contains 13,500+ files.

I generally maintain a list of between 20 and 160 active torrents visible in ktorrent. Of these, 20 torrents are torrents which I have a reason to continue seeding {hence the lower number} while the balance are torrents in various stages of activity.

The 'seeder' torrents are not all active at the same time. This means that I will always have two groups of completed torrents. Those I'm actively seeding and those I am not currently seeding. Ktorrent makes this distinction.

The remaining torrents can be grouped as follows: inactive {never started}, inactive {stopped}, queued and actively downloading torrents.

Inactive {never started} torrents are usually torrents I've come across but haven't yet decided to actually download. Consider them placeholders awaiting me to make up my mind.

Inactive {stopped} torrents are torrents where there is some kind of issue. Usually, these are torrents where the torrent isn't yet fully seeded or the available seeders are blocked.

Note that ktorrent makes no distinction between {never started} and {stopped}. This is a purely mental distinction in my own mind.

'Queued' and 'active' are, of course, self evident.

The above should make both the scope and expectations I might have from ktorrent's GUI more understandable.

Finally, under my personal normal usage, I have the upper half of the ktorrent screen set with the torrent listing while the lower half is set to the 'Queue Manager'. I'll change function of the lower half as needed for a given task, but normal usage is predominantly with 'Queue Manager' open.

Torrent listing {Top half of GUI}

Thing{s} I can no longer do

I can no longer sort the torrent listing by torrent status. The relevant KDE bug reports are the change Bug #272160 and someone else's notice Bug #287013 {read: complaint} of same.

I'm not going to suggest that #272160 be reverted. I understand the rationale behind it. Effective management of screen real estate is a good thing.

However, #287013 doesn't explain why this is a problem. Not only do I agree with the poster of #287013 that this is a problem, I personally find it frustrating and aggravating. Since this is so, I will endeavor to explain why this change is frustrating.

At one point in the past, I did experiment with 'Group View' for several months. I came to the following conclusion regarding 'Group View': This function is really applicable to people who need to keep track of 250 torrents or more. Smaller lists of torrents don't really have a need to be broken down further into user defined 'Groups' for easy management.

I mention this just to make it clear that I have used and believe I understand 'Group View' concepts and functionality.

Further, with such a small list {relatively speaking} of torrents, it becomes practical to turn off the 'Group View' function completely. Instead, simply sorting by 'status' is sufficient for effective group management.

To understand how this worked prior to version 4.2, I simply clicked on either 'Name' or 'Size' as my initial sort, then clicked on 'status' to group the listing and finally clicked on 'time left' for force all actively downloading torrents to the bottom of the list. When you're dealing with less then 200 torrents, this is a very effective way to group and manage your torrents. Since 'Group View' isn't needed, the extra space across the screen becomes a welcome addition.

Since, with 4.2, the 'status' column is now removed, I can no longer sort and group my torrents accordingly.

Group View is Broken

There are two different problems with attempting to use 'Group View' to replace the above lost functionality.

Problem 1: This is conceptual in nature. The included filters in the 'Group View' are just that; filters. This means that they are exclusionary in nature. I can view any one status group of torrents. I cannot view a full listing of status sorted groups of torrents. i.e. Group Viewing is not a replacement for sorted status viewing.

Problem 2: This is an actual bug {or possibly multiple bugs}. Whether this is a 'design' {i.e. Works as designed.} bug{s} or a program bug{s}, I don't know and I'm not programmer knowledgeable in the field to determine. I suspect {strongly} that this is a design bug. Someone else will need to determine specifics. The problem is the interaction between the filters in the 'Group View' and the displayed list of torrents.

If you have a list of torrents in various statuses and you click on {for example} 'Active Torrents', all torrents other than active torrents are filtered out. Active torrents are left in the order in which they were originally listed. If you click back on 'All Torrents', you don't get your original {unfiltered} list back. Instead, all the non-Active torrents are appended to the existing Active torrents list {from the just prior filtered results}.

If you {as a user} had gone through the effort to sort your full torrent listing prior to filtering just for Active torrents, that sorting effort is now completely worthless and needs to be repeated. And you need to repeat that sorting each time you perform a filtering action. This is not exactly the most useful behavior possible.

It would be much more useful and make the removal of the status column consequently less painful if each filter selection worked from the same original 'All Torrents' listing. The full listing should only be re-sorted on demand from the user when clicking on the listing columns. This is where the user expects and is trained for this kind of behavior. Turning filters on and off should not be grounds for resorting!

In other words, if the status column is gone, then the only possible functionality replacement is to make use of the 'Group View' filters. If use of the 'Group View' filters breaks my chosen sorting of my full torrent list, then 'Group View' is worthless for me.

Suggestion 1:

The status icon is included as part of the display of the 'Name' column. If possible, perhaps the status icon {and only the status icon} could be made it's own sortable column. It should be noted that the alphabetical sort of the status column was, of itself, unimportant {i.e. order of groups didn't matter}. Rather, it's the actual grouping of all torrents by status which was useful.

Suggestion 2:

Revisit the display list and 'Group View' filtering logic and make it rational.


Queue Manager {Bottom half of GUI}

Queue Manage is Seriously Broken:

The 'Queue Manager' also has two different problem areas. The interaction of these two problems areas is synergistic in nature. i.e. These problems are not 'additive' in nature. They feed each to make mountains out of mole hills.

Problem 1: The 'Queue Manager' now has the addition of filters. I'm going to go out on a limb here and suggest that the filtering and list appending behavior we see in the filtering 'Group View' behavior above either shares the same or near clone internal list manipulation routines. This is a much worse result for the 'Queue Manager'. Why you ask?

As far as I can tell, when a filter is turned off {i.e. the filtered out torrents are re-listed}, the order in which ktorrent will attempt to process your torrents may or may not {almost certainly not} match the order they are listed on the screen. This is a big bad no-no.

But wait. It gets worse.

In order to get the displayed queue processing order to match the actual order ktorrent will attempt to process your torrents in, the only way I've been able to get close is to press each of the filtering buttons twice.

Allow me to be absolutely clear on this. If you use any filter button on the Queue Manager, you need to unfilter that button. Then you need to cycle through a filter and unfilter operation on each of the three filter buttons before you can have some confidence that the order of the listing you're presented with matches what order ktorrent will attempt to process your torrents in. I hope that's completely clear to everyone.

It gets even worse!

If you attempt to arrange torrents after a single filter click and unclick , the torrent{s} you move will almost certainly not be the one{s} you think you moved to the locations in the list you think you moved them.

Problem 2:'Queue Manager' was a bit broken to begin with when it came to selecting the next torrent to start. That problem is now worse. Note: I haven't searched the bug database to see where these bugs may be listed. I do consider them program bugs but they were minor to me and the minor pain did not impel me enough to report them. I'm bringing them up now because the pain has gotten much, much worse.

Prior to 4.2, there were two different scenarios with how ktorrent picked the next torrent to process.

Scenario 1: If you had a list of torrents with various statuses and you added a new torrent by clicking on a torrent link in a browser, the new torrent was added to the Queue list at some point above the bottom of the queue. This was minor because, for that torrent session, new torrents were always added at the same point.

Scenario 2: When you had more than one torrent queued and ready, the next torrent activated was either the first or second queued torrent in the list depending on certain circumstances. If the next torrent started was not the first torrent in the queue, then the first torrent in the queue dropped down the queue list to some point above where the point were new torrents were added {see scenario 1} but after the last actual torrent queued for downloading. If there were three or more torrents queued for downloading, torrents would be processed as every other torrent with the unprocessed torrents dropping to the same in between point in the list.

With 4.2, not only is the same above behavior still present Scenario 1 is much worse. The new torrent is added as in pre 4.2. But the displayed list is re-ordered!

But wait! .. You knew this was coming, right? It's even worse!!

The queued order ktorrent wants to download torrents in actually hasn't changed. Just the displayed order is changed. Yikes!

Trust me on this one. You want to cycle through all the filters in Queue Manager several times after adding new torrents if you want to have any hope at all of seeing what order ktorrent will process your torrents in.

I have no specific suggestions for Queue Manager. It's seriously borked.

Currently, I just actively monitor what's going on and make re-adjustments as needed.

Ktorrent has their own forums (development and help) http://ktorrent.pwsp.net/forum/viewforu ... 223dc98592 you might want to post there

google01103 wrote:Ktorrent has their own forums (development and help) http://ktorrent.pwsp.net/forum/viewforu ... 223dc98592 you might want to post there

Thank you for the tip. I wasn't aware of that. I will re-post this there. Should I do anything here to indicate a status such as [MOVED]? {as opposed to [SOLVED]"?

I'd just post a link to the post on their forums

google01103 wrote:I'd just post a link to the post on their forums

Done - edited my OP to include notification of cross-posting.

FWIW - I also added some suggestions regarding 'Queue Manager'. I'll include them here as well for anyone who's interested.

I said above that I didn't have any suggestions regarding Queue Manager. After sleeping on it yet again, it turns out that I actually do have some suggestions.

Suggestion 1:

The column labeled 'Order' is part of the problem. I believe it is implemented with the concept that the torrents will always be listed in Queue order and therefore the column 'Order' only needs an incrementing count. This means that the column labeled 'Order' is actually 'Displayed Line Count'.

This is wrong for two reasons. The first reason is that torrents which are already 100% complete are, by definition, no longer part of the set of queue-able torrents. Therefore, their 'Order' should be null. The second reason is that 'Display Line Count' has no actual association with torrent objects. Any perceived association is a figment of the imagination and must be separately {and rather tediously I'm sure} maintained. This makes it easy for the value shown in 'Order' to become out of sync with the actual queued processing order.

The column 'Order' should be treated as a characteristic just like 'Status' or 'Time Stalled'. The column 'Order' should then display this maintained characteristic. 100% completed torrents should display 'null' and all other torrents should display the assigned value of 'Order'. 'Display Line Count' should never be displayed.

The concept of 'display filters' will then make sense as where any given torrent's place in the {sometimes hypothetical} processing queue will be displayed as an associated maintained value.

Suggestion 2:

100% Completed torrents simply shouldn't appear at all in the 'Queue Manager' window. As torrents complete, they should disappear 'in real time'.

Suggestion 3:

If 'Order' becomes a characteristic of the object 'torrent', then it might be possible to add an 'Order' column to the torrents listing and do away the Queue Manager display window altogether.

Initially, a 'Queue Manager Mode' could permit manipulation of the 'Order' values. Later, that functionality could be integrated/implemented into the torrent list just like 'sort' functionality.

Of course, YMMV. Everyone has an Opinion. I am not a Programmer. yada-yada-yada

BTW - I've determined one of the ways the Queue Manager listing becomes weird is that addition of a new torrent now causes the displayed queue listing to become inverted. Last becomes first and first becomes last. I didn't realize this earlier because my list was too long to easily see the inversion. The actual queue order doesn't change {other than the insertion of the new torrent into a place somewhere before the end of the queue}. But the displayed listing order is, of course, nonsensical.