Description: Connected spinbox not updated when value is typed into the field Steps to Reproduce: 1. Open Writer 2. Insert a 3 column table 3. Table Properties -> Column tab 4. Type a width for column A. notice column B not being updated. 5. Press OK -> 6. Open Writer 7. File Export ( 9. Pick JPG & a directory 10. Press Save.. JPG options dialog opens 11. Switch to Modify Resolution 12. Type some value 13. Notice the dimension field not being adapted.. press TAB.. now it does Actual Results: As long as the cursor being inside the field.. nothing happens Expected Results: Well, so way to trigger an update.. Simply force an update every second (after last keypress?) for example? The current UI feedback is really inconvenient (not user friendly). And going backwards compared to older versions Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 05ff3d67d0e2e436406786c949eb7cfca107ba33 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
@Caolán I have brought this up a while ago.. The assessment back then was, that the problem was inherent to the working of those spinboxes :-(. I'm not content with current state.. they lack of feedback is really really annoying... [I assume UX having the same opinion...] Has there been some change to those spinboxes in the mean time which could solve the issue here? Or is there some spinbox variant/alternative which does behave? Or is it possible to simply force an update every second (after last keypress?); Maybe only for those spinboxes which are interconnected.. -- Case 3 (comment 0 has 2 other cases) 1. Open Writer 2. Insert a Image 3. F4 4. Type tab 5. Check keep ratio 6. Type Width -> Notice height not changing..
When you leave the control per tab into the other spinbox the values are updated. Since it depends on each other I don't see how this can be done on-editing. Point is that while editing a value the depending are volatile and must not be updated before finished. => NAB (and there are likely duplicates)
(In reply to Heiko Tietze from comment #2) > When you leave the control per tab into the other spinbox the values are > updated. Since it depends on each other I don't see how this can be done > on-editing. Point is that while editing a value the depending are volatile > and must not be updated before finished. => NAB (and there are likely > duplicates) Case 2 (JPG export) and Case 3 (comment 1) did work in previous versions.. Fine with Version: 6.2.0.0.alpha0+ Build ID: 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b CPU threads: 4; OS: Windows 6.3; UI render: GL; Locale: nl-NL (nl_NL); Calc: CL broken since Version: 6.2.9.0.0+ (x86) Build ID: 5f01fe15eb2661f1f9ce12d1d99dc2a705b462ee CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL -- A) this did work previously B) Most image software I use does give feedback. C) It does work if you press arrow/up down inside a spinbox (without leaving). D) It does work if you scroll/up down inside a spinbox without leaving E) It does work if you press arrow/up down buttons of the spinbox without leaving If we take this as a rule: "While editing a value the depending are volatile and must not be updated before finished" we end up cases C-E being bugs :-) They only thing needed some code triggering a refresh for connected spinboxes at each keypress inside the spinbox.. Which would mimic cases C-E.. You get live feedback; and the UI would represent the end-result when pressing OK without leaving the control; The UI simply misrepresenting the actual case. which is confusing.. Especially if other software does work this way and LibreOffice being quirky exception.
I think we can change the interaction handler from "OnChange", fired on exit or when the spin buttons are pressed, to "OnKeyUp" that handles all value changes. But it would be quite annoying when values changes all the time and you enter something in A, switch to B, and get A changed again when modifying B. What I mean is: The cases when it make sense are rare (the export dialog might be one). It is an error-prone modification since you have to take care of ranges yourself. And last but not least, users are familiar with this method as Caolan implements standard behavior. If we implement a check-and-update-on-input behavior it needs to be done very carefully and only when needed.
(In reply to Heiko Tietze from comment #4) > But it would be quite annoying when values changes all the time and > you enter something in A, switch to B, and get A changed again when > modifying B. 1. This does happens in cases C-E (at comment 3); (Aside, plenty of programs do this this way] 2. If something being interactive input, this should be expressed 3. Not all programs change Image size based on DPI. Or change other columns sizes, based on input in one field.. So if size not responding.. I assume no connection between DPI & Size. 4. Showing something else in the dialog, compared to what you get when pressing OK (without leaving the spinbox) is wrong. The dialog should represent what you get.. > What I mean is: The cases when it make sense are rare (the > export dialog might be one). The cases where spinboxes are connected are limited (not that rare). If you start looking you might find more :-). Not sure if you can git grep all those cases :-). Like insert Section dialog; Column tab or Table properties dialog: Table tab (typing spacing affects, total size > It is an error-prone modification since you > have to take care of ranges yourself. Sorry, I'm not sure what you're trying to say.. with 'care of ranges? > And last but not least, users are > familiar with this method as Caolan implements standard behavior. The current behaviour isn't consistent :-). And it did work this way in the past (in a number of cases..) > If we > implement a check-and-update-on-input behavior it needs to be done very > carefully and only when needed. O well this should be done "cautious obviously". I have no clue if change can be limited to connected spinboxes [so if there is a way to filter/identify those]. I would assume this being possible, as the (inter)dependence set somewhere.
Created attachment 174881 [details] SpinButton in MSWord 2013 with connected preview a video demo of MSWord
Created attachment 174882 [details] SpinButton in gedit (gtk3) with connected preview
FWIW word works this way, the stock gtk spinbutton works this way (the gedit case) and I've no plans to change it. I had some longer comment the last time this came up with the issues with emitting value-changed during arbitrary user editing
Created attachment 174884 [details] Screencast (In reply to Caolán McNamara from comment #8) > FWIW word works this way, the stock gtk spinbutton works this way (the gedit > case) and I've no plans to change it. I had some longer comment the last > time this came up with the issues with emitting value-changed during > arbitrary user editing Hmmm, we have some misunderstanding - I think - about context & scope. The screencast is about spinbox being applied to preview. This is about input fields which are dynamically interacting the other fields (except not being visible). I admit there is some 'overlap' (so not completely different). However a 'preview' not updating is slightly less problematic, IMHO. Screencast of IrfanView updating size on typed input
The recording in comment #9 isn't a spinbutton though. I can't tell either if there are min/max bounds to the values that can be entered and what happens if the user temporarily enters text that would exceed the limits while editing.
Created attachment 174898 [details] Screencast Paintshop Pro
Created attachment 174899 [details] Screencast XnView
Created attachment 174900 [details] Screencast Faststone Image viewer
Created attachment 174902 [details] Screencast PhotoScape Gimp/ RawTherapee & DigiKam/ Avidemux behave like LibreOffice Dynamic * https://pixlr.com (not spinbox() * Nomacs (QT5) It appears that the behaviour more or less platform depended. Dynamic updating rather common for Windows applications (with some exceptions), but only updating after focus change appears to be the norm at Linux environments (with Nomacs being an exception).
Looking through old unconfirmed bug reports, I had a look at this one. After reading it looks to me as there is the question, if it should be changed to WONTFIX or not. Is it possible to make a decision here?
(In reply to Dieter from comment #15) > Looking through old unconfirmed bug reports, I had a look at this one. After > reading it looks to me as there is the question, if it should be changed to > WONTFIX or not. Is it possible to make a decision here? No further input for more than a year. So I Chance status to WONTFIX. Telesto feel free to change it back to UNCONFIRMED with a short reasoning, if you disagree.