[Feature Request] When renaming files/torrents (F2), make the behaviour more WIndows-like

[StentMan]

When you select a file in windows and press F2 to rename it, only the file name part is selected, not the whole file name + extension. Currently, TrguiNG doesn't behave like that.
It would be convenient if TrguiNG would behave like that as well (at least on Windows).

[qu1ck]

Fixed for files list.

Note this will not work in torrents table (previous behavior is maintained) because it's impossible to know if torrent name is a file name or a containing folder name without downloading file list for all torrents all the time which is wasteful and will significantly increase bandwidth.

[StentMan]

Awesome! Thank you for the quick response.

[reardonia]

Note this will not work in torrents table (previous behavior is maintained) because it's impossible to know if torrent name is a file name or a containing folder name without downloading file list for all torrents all the time which is wasteful and will significantly increase bandwidth.

There are a number of things that could be improved if things like files was cached and used in situations like this, rather than requested ad hoc. This is related to using recently-active rather than current update mechanism. Why download the file list "all the time"? It is almost-never changed, if it is does change that it will be reflected in recently-active

[qu1ck]

Files list should never be downloaded for all torrents, does not matter if its cached and only downloaded once. It's a waste of ram and significant load on server when you have thousands of torrents.

[reardonia]

Files list should never be downloaded for all torrents, does not matter if its cached and only downloaded once. It's a waste of ram and significant load on server when you have thousands of torrents.

Why or how is it a load on the server? I don't agree. You grab this data ONCE and basically never again. That is the whole point of recently-active and why we made a big investment in it within the daemon.

I guess this is a different philosophy taken by some other clients, Transmission-Remote-GTK in particular, which has a lighting-fast responsive UI. I'm a lot more concerned about memory usage in the daemon than I am in the UI. FWIW I run a test daemon with >10,000 torrent.

That said, you could also solve this problem by doing the files request immediately when a torrent is selected in the UI, which is required before F2 has any effect.

[qu1ck]

Why or how is it a load on the server? I don't agree. You grab this data ONCE and basically never again. That is the whole point of recently-active and why we made a big investment in it within the daemon.

If by never again you mean until next app launch, which is quite often for people who dont like keeping the app open all the time, then yes. On a slow CPU hardware daemon struggles with large api requests as is, downloading tens of megabytes of data on every app launch is a no go in my opinion. I guess it could be an opt in feature.

I have nothing against recently-active, in fact I plan to implement it but it does nothing to reduce first time load and I'd rather request the bare minimum fields that are required to show the torrent table.

FWIW I run a test daemon with >10,000 torrent.

I bet you are not doing it on a 800mhz 2 core arm cpu from yesteryear. My old NAS was slow with ~1k torrents and if you had a rehash operation going on at the same time you might as well go for a cup of coffee if you wanted to fetch the torrent list.

That said, you could also solve this problem by doing the files request immediately when a torrent is selected in the UI, which is required before F2 has any effect.

1. When selected, request with all fields is made for details pane but there is no guarantee I will have a response by the time f2 is pressed.
2. Torrent is not required to be selected to press the rename button.

[reardonia]

I have nothing against recently-active, in fact I plan to implement it but it does nothing to reduce first time load and I'd rather request the bare minimum fields that are required to show the torrent table.

Great news that you'll take on recently-active !

I bet you are not doing it on a 800mhz 2 core arm cpu from yesteryear. My old NAS was slow with ~1k torrents and if you had a rehash operation going on at the same time you might as well go for a cup of coffee if you wanted to fetch the torrent list.

Hash verification is on its own thread now (for several years at least) so that should happen.

I just think it's a trade, slower startup in exchange for more responsive UI and significantly fewer ongoing requests. But I respect your desire to use resources efficiently.

[qu1ck]

I agree, there are cases where its beneficial, especially if you have a fast server and connection. So it could be an option. But it really should be in a separate issue.

[reardonia]

I agree, there are cases where its beneficial, especially if you have a fast server and connection. So it could be an option. But it really should be in a separate issue.

I think it's properly considered as part of the recently-active issue opened previously? otherwise happy to open new issue.

[qu1ck]

These are 2 separate issues, please open a new feature request for caching all data upfront.