Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

BUG - OK/enter captured by wrong window

by Guest on 2024/09/04 02:00:55 PM    
This is on new v3.29 (I upgraded from a much older version, so I don't know how far back the regression goes, but it didn't happen before).

Start a new torrent from a magnet link. When the window opens to confirm the local file details, choose to rename any file in the torrent. This SHOULD be a modal dialog window - OK or cancel are the only options and ways to leave the renaming window. If you press enter as a normal shortcut for OK in this renaming window, however, the key is captured by the main underlying torrent window instead and the torrent starts, perhaps before you've finished doing any other renaming. This is NOT normal interface behaviour for a modal dialog.

I'd also point out that while the non-standard interface is generally good, it is VERY good practice interface design to indicate the default button in a dialog with bold text or a highlight of some kind, so you know which button the enter key will activate. Your attention to this would be appreciated by many, I'd guess.

Also on the subject of key-capture, I've been caught out a few times switching between machines/keyboards when Tixati has had the focus in the other machine and I've pressed delete on the wrong keyboard. The default action of the delete key is to remove the torrent AND files completely without a confirmation dialog, which is very destructive if you realise you've made a mistake. Confirmation of choice on this key-press would be very helpful, or restricting it to the torrent only, NOT the local files.
by Guest on 2024/09/09 06:17:00 PM    
There's an additional unfortunate bug related to this file-rename dialog. If you are editing a filename while new torrents are incoming (typical if you have just queued a number from a search site), when the magnet link is downloaded/parsed and added to the transfers this dialog loses focus, even if you are in the middle of typing. Again, this should never happen with a modal dialog.

Also, the new behaviour of the transfers list when you start/stop a torrent, following it in focus to the top or bottom of the transfers list, is extremely annoying. Since there's no way to simply reorder the torrent list as they are initialised on disk other than their order of magnet parsing (you really don't want a huge torrent hogging the single initialisation routine when you have a few small ones you'd like to start in front of it), stopping and starting large torrents to order them in size and put them at the end of the list for initialisation is the only brute-force option available. Having to scroll back up/down the list after every stop AND start to find the next is tedious. Is there a way to turn off this behaviour?
by Guest on 2024/09/12 03:51:43 AM    
The default action of the delete key is to remove the torrent AND files completely without a confirmation dialog, which is very destructive if you realise you've made a mistake. Confirmation of choice on this key-press would be very helpful, or restricting it to the torrent only, NOT the local files.
This is a long-standing request, and really, it's just so obvious that the existing behavior is ridiculous and dumb. Why would the dev ever think it was a good idea to implement the Del feature in such an insane manner?
by Guest on 2024/09/12 04:41:47 PM    
The default action of the delete key is to remove the torrent AND files completely without a confirmation dialog, which is very destructive if you realise you've made a mistake. Confirmation of choice on this key-press would be very helpful, or restricting it to the torrent only, NOT the local files.

This is a long-standing request, and really, it's just so obvious that the existing behavior is ridiculous and dumb. Why would the dev ever think it was a good idea to implement the Del feature in such an insane manner?

Have either of you looked in the settings?
settings - transfers - files
file delete method option
it has 4 choices
-confirm delete
-confirm delete/trash
-confirm trash
-direct to trash

so no way to accidentally lose a torrent/file.
and you can undo an accidental remove.
by Guest on 2024/09/14 11:32:53 PM    
so no way to accidentally lose a torrent/file
You know, when you make uninformed statements like these without actually testing or even understanding the issue being described, it only serves to make you seem dumb.

I have Confirm Delete/Trash selected under Settings. Accordingly, when I have one or more torrents selected in the list and press the Del key, a dialog dutifully pops up asking me whether I want to Delete/Trash/Keep the files. Note the word in bold there = files, not torrents.

If I select Keep, the partially downloaded files are indeed retained, but the torrent(s) get deleted from the list immediately when the Del key is pressed, and there is no trace of the actual .torrent files anywhere unless you happened to explicitly export/save them earlier.

So yes, the way the Del key behaves right now is completely retarded, since it results in immediate and irretrievable data loss.

Do you get it now? Stop trying to defend the indefensible. After all, we're bothering to complain here because we want Tixati to improve, and blind fanboy-ish comments don't help.
by Guest on 2024/09/15 02:57:24 AM    
did you miss the part where you can undo a remove/delete of a torrent?
if you delete/remove something accidentally you can right click the remove button and undo the last remove.
by Guest on 2024/09/17 01:00:43 AM    
The fact that there's an undo hidden in the context menu of the Remove button in no way excuses the sheer ridiculousness of implementing immediate torrent removal from the list without asking for confirmation first.
by Guest on 2024/09/28 04:30:17 PM    
Original poster here - for me, whether or not there are some (rather well-hidden) ways to mitigate it or not, it's the fact that unconfirmed removal of the torrent AND files is the DEFAULT is the problem. A default option should never be so destructive. After all, you may have spent days downloading something, and the last thing almost ANYONE would want to do then as a DEFAULT option is to remove everything without any dialog confirmation whatsoever. :/
by Guest on 2024/09/29 10:02:11 AM    
file delete method option has 4 choices
-CONFIRM delete
-CONFIRM delete/trash
-CONFIRM trash
-direct to trash
by Guest on 2024/09/29 02:09:17 PM    
Yeah, that's been pointed out above, that's not new information. The problem with it has been stated above by someone else. Even if you find those options in the Tixati preferences, they aren't protecting you the way you might think - keeping unusable partial files but silently junking the torrent that'll allow you to complete them is really not a great idea.

And what exactly is the difference between "Delete" and "Trash"? For most people they mean exactly the same, so almost every user will skim over that setting without checking it or understanding what it does. Do you? I'm not sure I do. :/

There is a setting below: "Allow deletion of created transfer local files". That might be the way to prevent this, but in my installation it's unchecked and this is still happening to me when I press the delete key accidentally, so that clearly doesn't work the way a user would expect either. :/
by Guest on 2024/10/19 03:51:27 AM    
(FWIW I'm a "Guest" different from all the other posters)
I think my Tixati defaulted to confirm delete, but it's been so long I can't be sure. If it really defaults to direct to trash on some installs/versions, then that is worrying.
Trash is supposed to send the files to recycle bin instead of deleting them, but on network files or some removable drives it is the same as delete. Even on normal drives there is a limit to the files it can contain so a torrent with big files like DVD or Blue-Ray ISOs, large archives and such may get directly deleted.




This web site is powered by Super Simple Server