Info about current item/selection in the status bar

[Kervius]

The left side of status bar in QBT is empty. (Well, I haven't seen it being used at all.)

It would be nice for it to be have like the status bar in the Explorer (e.g. in WinXP) or iTunes, displaying short info about the currently selected item(s):

• size on disk of the item(s)
• number of files in the item(s)
• if only one item selected, also show the save path

I personally interested in: the size on disk for multiple items and the save path of a single item. But number of downloaded files might be also useful.

[sledgehammer999]

That's why we have the various columns in the transfer list. We shouldn't display info all over the place. We want a "clean" UI.

Also that part of the status bar needs to be empty. Currently it is used for one rare warning. It needs to be empty to catch the eye of the user for when the warning appears. And in the future it might be used for other warnings/errors too.

[Kervius]

@sledgehammer999 "That's why we have the various columns in the transfer list." For ONE item. If MULTIPLE items are selected.... One might as well suggest export of the grid into a spread sheet :D

"Currently it is used for one rare warning." What is the warning? I found only the executable update warning. If that's it, then it is a bad UI choice: you should add "Restart" button to the main toolbar instead or something like that. Because you do not want user to close the application upon seeing the warning. You want user to restart the application to let the update take effect. Why the half-step with the warning then? Why not button which does it for user?

P.S. Think of the relatively common use case: clean up of the old torrents. The list of problems I have encountered during my last one, FYI:

• No persistent selection or similar. (After selecting 50+ torrents, any wrong click resets the selection and undoes half an hour of work. Can be solved by multi-labeling. Or persistent selection (but it is not a common UI paradigm; see KDE's Dolphin and Apple iTunes).)
• Impossible to lock sort order. (Accidental click on the header of the torrent's list causes resort and you are lost in the see of torrents. Aggravates the first problem.)
• Impossible to see how many torrents are selected. Easy to lose count. (The only useful torrent count displayed in qbt is in the labels display. The "All (%u)" count is too high to be usable.) Hard to verify the end results: there were 100 torrents under this label, now 80, thus I must have deleted 20.
• Impossible to see how much of the disk space would be actually freed by the removal of the selected torrents.

I have opened a ticket with a proposal for the last, since it is the one which is impossible to handle otherwise. And it also serves as the main justification for going through the clean-up trouble at all.

[sledgehammer999]

Hmm, I misread your desc.

I am ok with displaying how many torrents are selected + total size.

No persistent selection or similar.

I don't like persistent selection. It will confuse most of our users. Multilabeling is proposed and discussed elsewhere (use search)

Impossible to lock sort order. (Accidental click on the header of the torrent's list causes resort and you are lost in the see of torrents. Aggravates the first problem.)

I don't see how I can prevent this problem.

[Kervius]

@sledgehammer999, thanks. It's a wish list anyway. And actually, on the second thought, the update notification and summary info are not contradictory: update notification would simply override the summary info. When people would get used to seeing numbers/etc there, the warning image would be out of place and quite noticeable.

Impossible to lock sort order. (Accidental click on the header of the torrent's list causes resort and you are lost in the see of torrents. Aggravates the first problem.)

I don't see how I can prevent this problem.

You're really stretching my outdated Qt-foo. :)

Interwebs say QTreeWidget has (since Qt4.2) method setSortingEnable(). Also QSortFilterProxyModel::lessThan() can dumbly return false (and people say that would prevent sorting; quick test with qsort() proves that).

Though I gather it might be not as trivial, since one would have to reenable sorting temporarily when new torrent gets added, so that it would go into the right place. Or not. I'm not really aware of all the MVC shenanigans taking place. But judging by the recommendation in documentation to disable the sorting while populating the model to improve initialization performance, I guess it really rearranges the items inside the model.

[sledgehammer999]

Can you explain what do you expect from "header locking"? How does it behave? Does any other program implement this so I can test how it works in action?

[Kervius]

@sledgehammer999

Can you explain what do you expect from "header locking"? How does it behave?

For example:

• Right click on the header
• In the pop-up menu, after the toggle list of all the items available to display, after a separator, a toggle item "Lock Sort Order". If the toggle is Off (default) then clicking on the column headers causes change of the sort order. If the toggle is On then clicking on the column headers has no effect.

(Ideally: new toggle's name "Lock Header". If it is "On", header looses the 3D effect and becomes flat and: you can't move or resize columns, clicking on columns header has no effect. The 3D effect always served as the visual hint to the interactive GUI element.)

Does any other program implement this so I can test how it works in action?

Not that I'm aware of it. But then, not that many programs provide dynamic UIs.

Frankly, I'm surprised that it is all on automatically. In the past, in other GUI toolkits, one had to enable moveable/resizable/sortable header in grids explicitly.

Hm, actually it looks like Qt supports that too: http://qt-project.org/doc/qt-4.8/qheaderview.html - header()->setClickable(); header()->setMoveable(); header()->setResizeMode(). I do not have build environment for Qt apps so I can't try it, but it would be interesting to see the effect of setClickable(false). If conventions haven't change, that should disable the "click to sort" too, since nothing would be emitted when clicking on the header.

[sledgehammer999]

No, what I meant is this. Why do you need a "header lock"? What problem does it solve?

[Kervius]

No, what I meant is this. Why do you need a "header lock"? What problem does it solve?

Accidentally clicking on header changes the sort order. I set it once and normally never change it.

What's more. I always sort on "Added On", descending. But I personally do not care about the field itself and would love to have it hidden. But I can't have it hidden, because when I accidentally click the header and change the sort order, to restore it, I need to be able to click on the "Added On" header again.

[sledgehammer999]

So basically you want to sort by column A, lock on that, hide column A and have that sorting persist even though column A is hidden AND even tough you might click on column B. Right?

(column == column header in this context).

[Kervius]

Yes.

[sledgehammer999]

Then I can certainly say that I am not interested in implementing this. I don't think this problem affects many users, so there's no real benefit of adding this feature.

[dogancelik]

It would be nice if qBittorrent showed how many torrents are selected on torrent list at status bar, bottom left.

[maxiwheat]

+1 to show the number of torrents selected