Split from bug 90349 The behaviour of "Advance Slide" - "Automatically after:" in the Slide Transition sidebar is inconsistent and does not seem very friendly. - When "No transition" is selected, the "Automatically after:" field can be freely edited and is coerced to "0.00 sec" only after leaving the field. This seems reasonable to me - When any transition is selected, the format is coerced over-enthusiastically to "0.00 sec" while you type. The visual and logical behaviour of this seems sub-optimal. Whether a digit is inserted or deleted when typing depends on the position of the cursor and the current content, which means the user has to keep a complex mental model of what the effect of a given combination of position/content/input will be. The user (or at least this user) would generally prefer to be able to add and delete characters at will to reach a desired number. In addition, when a digit is forced to be overwritten, a digit is first displayed being inserted, then deleted (causing ugly flicker) For instance, ("|" denotes the position of the cursor) "1.00| sec", type Backspace x3 => "100.00 sec" (surprising) "1|.00 sec", type Backspace, "4" => "40.00 sec" (surprising) "1.|00 sec", type "1" => briefly "1.100 sec" => "1.10 sec" (ugly) The only situation where the scheme which is currently attempted would make consistent sense is if the format (including the total number of digits) were truly fixed - e.g. always "000.00" - and attempts to delete the decimal point were ignored. However, I would suggest that the most reasonable behaviour is that of the current "No transition" case, i.e. no coercion while typing at all. Additional suggestion: "Return" should format and confirm the currently input value
For reference, the most recent behaviour occurs since commit source-hash-65e5ce2c31803065551744ef1fa7b9572529aa45 in bibisect 43all, which is probably one or both of the below commits commit 1b2da3df5449f5bc517418cc632157780984e275 Author: David Tardon <dtardon@redhat.com> Date: Thu Feb 13 14:07:09 2014 +0100 enable spin-size for NumericField too Change-Id: I77660572947f7a863982be7742cbcb1c784379ed commit 78ff9d90f2a74792c437087ede11559c111c5c98 Author: David Tardon <dtardon@redhat.com> Date: Thu Feb 13 14:05:47 2014 +0100 fdo#74468 fix timing of slide transitions Regression since commit 16428c9600964a4945cf6fd0d938dea047d1248b. Change-Id: Id274c21e08d10d2e727f3b5a3fd852cd297e4637
Forwarding to UX for advice - as above, I feel this interface could be better than it is at present Thanks
Yup, there is a definite UI glitch in the widget used to set transition timer. Timer input is affected on both 32-bit and 64-bit builds (at least on Windows) when any of the transitions has been selected for a slide. Interesting in that if no slide transition is set--No transition--the Advance Slide -> Automatically after... widget behaves sanely. Lends to a simple work around, of resetting the transition to none, adjusting the timing, and then reapplying the transition. But shouldn't have to do that. @David T., thoughts why this gets munged when a transition is set?
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Adding keyword 'bisected' as the problem has been narrowed to 2 commits in comment 1
Cannot follow. Advance Slide > Automatically after is a numerical edit defaulting to 1.00s. I can edit the field without glitches under Windows 7 - it depends on the OS/DE how numerical steppers are handled, i.e. when exactly the auto adjustment starts, meaning onkeyup or onleave. Setting the ticket to NAB.