Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2603 closed Bug (invalid)

Deselecting individual torrents is ignored on Mac

Reported by: haravikk Owned by: livings124
Priority: Normal Milestone: None Set
Component: Mac Client Version: 1.76
Severity: Minor Keywords:


If you use select all (command-a) to select every torrent in your download list, and then use individual deselect (hold command and click a selected entry to de-select it), then any change you perform, such as right-clicking and pausing/resuming, or using the inspector to change priority, will be applied to /all/ torrents.

It seems as though the de-selection of individual torrents, after performing a select all, is completely ignored.

To summarise:

  • Press command-a to select all torrents.
  • Command click one of the selected torrents.
  • Open the inspector and change priority.

Result: All entries have their priority changed, including those which are no longer selected.

Expected: Only selected items should have their priority changed.

Change History (12)

comment:1 Changed 12 years ago by livings124

I can't replicate this. Do you have groups view enabled and have the group header selected - having that selected automatically has it apply to all the torrents in that group.

comment:2 Changed 12 years ago by livings124

  • Resolution set to worksforme
  • Status changed from new to closed

comment:3 Changed 12 years ago by haravikk

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Ah yes I do, so that seems a likely explanation. In that case then I suppose this ticket is misfiled; should I continue to use this one or produce a more specific ticket?

As it seems that the group header should automatically deselect if some of its contents are deselected by the user.

comment:4 Changed 12 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

Nah, I disagree. Current way is consistent with other apps.

comment:5 Changed 12 years ago by haravikk

  • Resolution invalid deleted
  • Status changed from closed to reopened

How is ignoring the user desirable behaviour?

If I deselect something I expect it to, oh I dunno, be deselected? If this is how other apps have been doing it, then it is bad interface design on their part, why emulate it? By all means, allow selection of a group to select its contents quickly, but it shouldn't then override subsequent actions the user takes; grouping is an organisational tool not a structural one, it's not like removing a folder in a file system which is an all-or-nothing operation, it's purpose is to associate similar items under some kind of heading.

comment:6 Changed 12 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

This is how every app behaves. If you have the header of the group, it should apply to all the items in the group. The app can't mindread to see what you were thinking.

And so far you have been the only user dense enough to not get this.

comment:7 Changed 12 years ago by haravikk

  • Resolution invalid deleted
  • Status changed from closed to reopened

It doesn't have to "mind read"; I, AS A USER, CHOSE to DESELECT AN ITEM. Transmission decided instead that this item is still selected. That is a BUG, or FLAWED BEHAVIOUR.

It's not my fault if you can't see this, but it's practically GUI 101 hell, common-sense, that if a user tells the program to do something, that the program should go ahead and try to do it, not just ignore them.

I mean, what the heck else could I possibly want if I /deselect/ something? I'm not just doing it for kicks!

A grouping is a selection aid, or organisational tool, if Transmission is using it as some kind of super-level entity in its own right, then it is using it incorrectly. Correct behaviour would be for all items in a group to be selected if the group is selected, and if one or more items in the group are then deselected, then the group is also deselected (as the entire group is no longer selected).

Alternatively; the select all feature should not select a group if it is open, because otherwise it is introducing a "double-selection", which is nonsensical behaviour.

comment:8 Changed 12 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

I, as the developer, am saying that you are wrong. What happens if I select a group heading? It means to apply all. Then if I select both a group heading and an item in the group, it only makes sense to apply to all. But I guess you do understand interface design better than I do... All the sub-behavior you are recommending just adds confusion and inconsistency. If you do not want to apply to the group, deselect the group heading - this is consistent with the Finder and all other apps.

Please do not reopen this again.

comment:9 Changed 12 years ago by haravikk

The difference between a grouping and a hierarchy is a very subtle one, as one is an association while another is a structure. To be blunt I don't agree with the Finder's behaviour either, as it is not clear at all what it is going to do with a nested selection, and indeed many of the operations behave differently.

For example, the move to trash operation simply cannot move some items while excluding others if a parent folder of all those items is selected, as the non-operation of leaving some items in place cannot work if their parent folder is moved (as they would become orphaned and therefore for most purposes destroyed). Labelling however works just fine, as the operation does not normally apply to children, and so the additional selection is useful in that case.

In this case however I don't think the issue should be dismissed, as the group itself is a non-entity in many respects, while a folder actually exists in a way.

In this instance the problem could be assumed to arise from the fact that select-all is doing more than simply selecting all torrents as I would expect. Since a grouping is not an entity in any real-sense, I think therefore that the best compromise would be for select-all to no longer select the header of an open-group, as there's no reason to, since the individual torrents are selected anyway. Closed group-headers would still be selected as otherwise their contents would be ignored.

comment:10 Changed 12 years ago by livings124

In this case, I think doing what is most expected is what's best. Select all selects all, and a selected group applies to all in the group. No unneeded inconsistent or unexpected behavior.

comment:11 Changed 12 years ago by haravikk

Selecting a group as part of a select-all operation produces inconsistent and unexpected behaviour because it doesn't mean anything unless the group is closed.

The act of selecting a group header in addition to all of its child-items doesn't do anything useful as the group itself cannot be manipulated, so all you end up doing is double-selecting the child items, which is a counter-productive operation! It serves to add additional steps in order to deselect a single item.

If you wish to modify 35 out of 40 items, you end up having to do a select-all, scroll up, deselect the group-header, and deselect the items you don't want to modify. This is unintuitive, and especially frustrating if the items you need to deselect are usually at the tail end of the group (common if you sort by progress), as it means scrolling up and down to achieve the operation.

comment:12 Changed 12 years ago by livings124

This isn't going anywhere. Let's just agree to disagree.

Note: See TracTickets for help on using tickets.