Opened 11 years ago

Closed 11 years ago

#3772 closed Bug (fixed)

edits in the Preferences and Properties dialogs are applied prematurely

Reported by: brgnm Owned by: charles
Priority: Normal Milestone: 2.13
Component: Qt Client Version: 2.13
Severity: Normal Keywords:
Cc:

Description

The current 'instant apply' behavior is nice when it works, but annoying or confusing in some cases.

qtr is often used as a remote gui, so it should perform acceptably over slow/laggy links.

If the session is large, there may be several seconds delay between keypresses when using the filter box. I have resorted to copy-pasting the search text, which is definitely more cumbersome than pressing enter.

When changing transmission preferences, 'instant apply' can cause some unexpected behavior such as when changing 'max peers' from one 3-digit number to another: typing in the desired value causes all but a few peers to be immediately dropped. For this reason, I am also in the habit of copy-pasting here. 'apply' button would be easier and more clear, though possibly optional, as I guess some prefer this.

Change History (10)

comment:1 Changed 11 years ago by rb07

Actually you don't need an "apply button", what you describe is a bug and it should be fixed by disabling update of the field when you are editing it, sending the value when you leave the field (with anything other than ESC which should cancel all changes), and of course re-enabling the update.

This has been a bug on Transmission-Qt from the start. Anything you change goes piece by piece (i.e. type 123, and the daemon receives 1, then 12, then 123... and sets whatever you where changing 3 times).

I'm planning to look at the code and propose a fix, but if Charles or Longinus00 do it first no problem.

comment:2 Changed 11 years ago by charles

  • Milestone changed from None Set to 2.13
  • Status changed from new to assigned
  • Type changed from Enhancement to Bug

I agree with rb07's assessment and have a patch.

comment:3 Changed 11 years ago by charles

  • Summary changed from Option for 'click to apply' to user changes in the Preferences and Properties dialog get applied before they're done editing

comment:4 follow-up: Changed 11 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in trunk by r11452. I tested out all the fields this touches and it seems to work fine. I wouldn't say no to either of you double-checking, though. :)

comment:5 Changed 11 years ago by charles

  • Summary changed from user changes in the Preferences and Properties dialog get applied before they're done editing to edits in the Preferences and Properties dialogs are applied prematurely

comment:6 in reply to: ↑ 4 ; follow-up: Changed 11 years ago by rb07

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to charles:

Fixed in trunk by r11452. I tested out all the fields this touches and it seems to work fine. I wouldn't say no to either of you double-checking, though. :)

Testing revision 11489, in Torrent Properties, Options, Idle: Stop seeding if idle for N minutes: the text field is still refreshing when I try to edit.

Perhaps now is behaving different, it returns the original value discarding my edits... but how is that better?

There's also a bug on that functionality, I have the maximum value that can be input: 9999, which is less than a week (6.9 something days), but the torrent has not stopped after 11 days of inactivity. With smaller numbers it does stop, I've used 2880 (2 days), and of course when I try to edit with earlier versions it stops immediately. Perhaps 9999 is the max that can be shown, and I probably input a bigger number; can't seem to find what it is using transmission-remote, do I have to learn to speak RPC? (just kidding).

Last edited 11 years ago by rb07 (previous) (diff)

comment:7 in reply to: ↑ 6 Changed 11 years ago by charles

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

Replying to rb07:

Testing revision 11489, in Torrent Properties, Options, Idle: Stop seeding if idle for N minutes: the text field is still refreshing when I try to edit.

Perhaps now is behaving different, it returns the original value discarding my edits... but how is that better?

I agree that's frustrating, but it's got a different cause than the issue laid out in this ticket. In fact it looks like a regression of ticket #2050, so I've reopened that ticket.

Closing this ticket again, as I think we are no longer applying the changes from entry fields and spinboxes until they're done being edited.

comment:8 Changed 11 years ago by rb07

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.12 to 2.13

Version 2.13 just did it again, its not always, but the problem (sending prematurely) persists.

I've only seen it once with this version, I estimate that I've edited text fields about 10 times, not a single problem until today.

comment:9 Changed 11 years ago by charles

rb07: I'll need more information before I can test this. Could you be more specific about where it's happening? For example, could you turn on the http debugging in session.cc and see /exactly/ which fields are sending prematurely?

comment:10 Changed 11 years ago by rb07

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

False alarm.

What happened was in Torrent Properties - Options - Seeding Limits - Idle:, by default it is on "Use Global Settings", when activated a default value of 30 minutes appears, that one is sent to the daemon before anything is edited, that seems to be correct, perhaps the default should be 9999 to prevent visible changes.

Note: See TracTickets for help on using tickets.