openscopeproject / TrguiNG

Remote GUI for Transmission torrent daemon
GNU Affero General Public License v3.0
279 stars 33 forks source link

Add "Resumed" status filter #117

Closed jpovixwm closed 7 months ago

jpovixwm commented 7 months ago

image

qu1ck commented 7 months ago

I don't see what is the value of this filter if it's essentially "everything not stopped". It is covered by "downloading" and "complete". Even if you can't combine them currently to get simultaneous view of both usually you need either one or the other.

It's also labeled misleadingly, "resumed" implies that it was stopped at some point and later resumed but it's not the case for torrents that were just added, for example.

jpovixwm commented 7 months ago

I've recently migrated from qBittorrent, where this kind of filter is available under the same name, and it felt to me like it was missing in TrguiNG. I guess this is just my personal preference, but I'd use this filter most of the time while using qB. It's useful for quickly filtering out torrents I don't care about, such as those that were stopped automatically after reaching the required ratio.

"Completed" doesn't work here, as it also includes torrents in the Stopped state. To me, it's more akin to "Active" || "Inactive".

Not sure about the labeling of this filter. It seems like "Active" wouldn't be a bad fit, but it's obviously already taken. The current "Active" and "Inactive" filters refer to network activity, rather than the logical state of the torrents, so maybe these labels could be relabeled to include that piece of information.

To me, "Resumed" is fine, though I may have gotten used to what it's called in qBittorrent after all this time.

qu1ck commented 7 months ago

Makes sense. I can see it being useful if you keep around old stopped torrents. I personally either keep torrents seeding or remove them from transmission and don't see a point in keeping them around but I have other means of organizing content outside of transmission.

My concern here is making the list of filters too long and having options that are rarely useful. It forces users to scroll down to more useful ones like labels or tracker filters.

I think this can be added but with "Running" label. There also should be a way to configure which status filters show up. "Magnetizing" is another one that is rarely useful imo.

jpovixwm commented 7 months ago

There also should be a way to configure which status filters show up.

I gave it some thought and came up with this mockup: image

As the drag handles are not part of their respective <Menu.Item />, aligning the chevron icon was not straightforward. Also, the divider line doesn't go all the way to the right. (Edit: it looks like this in the other context menus as well, so this is unrelated)

Do you think this approach is worth pursuing, or do you have something different in mind? I think a single dropdown entry (without child items) together with a simple modal could also work here.

qu1ck commented 7 months ago

That looks good. Only thing I would add is make "All torrents" locked.

If you do go this route, keep in mind that mantine does not have nested menus, I had to hack it with an invisible button and another menu for the torrent table. You can replicate that or maybe come up with a better way, either works.

jpovixwm commented 7 months ago

Or we could just add a separate context menu to the "Status" section in the filters pane, with the added functionality of being able to reorder the status filters to one's liking.

This one is likely the easiest solution to implement. The only thing to keep in mind is to disallow the deselection of the last remaining selected status, otherwise there's no way to bring up the context menu if all statuses are deselected.

BTW: you can already lock yourself out of the filters pane in the same way, if you hide all four filter sections, though this one could also be solved by making the whole pane react to context menu events - which is currently not the case:

But this is something that should have its own issue opened.

qu1ck commented 7 months ago

Separate context menu is much less intuitive. Since there is no visual separation of the widgets there is no expectation that context menus will be different. I prefer nested menu, even if it's more code.

BTW: you can already lock yourself out of the filters pane in the same way, if you hide all four filter sections, though this one could also be solved by making the whole pane react to context menu events - which is currently not the case:

I keep stumbling into this and then forgetting to fix it.

jpovixwm commented 7 months ago

I went with the nested menu approach and made the "Running" and "Magnetizing" filters hidden by default:

I figured I could just omit "All Torrents" from the list, rather than displaying it with a padlock icon and implementing special handling in the onClick handler and such.

I've replicated most of the submenu behavior from the torrent table's "Queue" submenu, but I came up with a different way to handle the positioning of the submenu. The original approach doesn't seem to behave well when the submenu is forced to appear on the left side due to not enough space being present in the viewport for the submenu to appear on the right side (there's a small gap between the main context menu and the submenu):

With my approach, I can measure the dropdown element itself, and size the fake target button accordingly, so there's no gap both when the submenu is shown to the left and to the right:

At the current state of this branch, there's a lot of duplicated logic between the torrent table and the filters pane. I suppose the submenu logic could be abstracted out to a custom hook, but that's for later.

Let me know what you think.

qu1ck commented 7 months ago

Looks good, thanks!