Tools > Options > Writer > Mail Merge E-Mail... A spin button may make sense for e.g. font size, but for a server port number.. one jumps from 45 to 587 or so.. Looks a bit odd ;) Version: 5.4.0.0.alpha0+ Build ID: 5a20df55ff829978c880b22e0a1f32c35d0ba30f CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-12-20_10:23:17 Locale: nl-NL (nl_NL.UTF-8); Calc: group
Interesting, this was changed from a regular text field to a spin button in 4.2. No idea why, but indeed, the old field suited better for the task. Jay, what do you think?
(In reply to Cor Nouws from comment #0) > A spin button may make sense for e.g. font size, but for a server port > number.. We debated this issue in the file services dialog in the CMIS and changed the port control from a spinbox to a regular input field. (In reply to Aron Budea from comment #1) > Interesting, this was changed from a regular text field to a spin button in > 4.2. No idea why, but indeed, the old field suited better for the task. Can you bibisect this so we can see what changed, so we can easily revert it?
Created attachment 130065 [details] details from bibisect-42max Working on debian-stretch in bibisect-42max repository, I see the spin button come into LibreOffice ... status commit s-h date ------ -------- -------- ------------------- good 11f7d374 9579db98 2013-07-10 14:17:46 bad 4445ac65 43f2c887 2013-07-10 14:27:31 I am removing keyword bibisectRequest and adding bisected. Guessing that this might not be too hard to fix, I am adding keyword needsDevEval.
(In reply to Terrence Enger from comment #3) > Created attachment 130065 [details] > details from bibisect-42max > > Working on debian-stretch in bibisect-42max repository, I see the spin > button come into LibreOffice ... > > status commit s-h date > ------ -------- -------- ------------------- > good 11f7d374 9579db98 2013-07-10 14:17:46 > bad 4445ac65 43f2c887 2013-07-10 14:27:31 > > I am removing keyword bibisectRequest and adding bisected. > > Guessing that this might not be too hard to fix, I am adding keyword > needsDevEval. Hi Terrence, It doesn't seem the problem was introduced by 9579db98 but it was by 43f2c887, am I correct?
Yes, Xisco, the bug was introduced by 43f2c887: commit 43f2c887a0ed365c2f06d29bb5fa5512cbcaf542 Author: Csikós Tamás <csks.tomi@gmail.com> AuthorDate: Tue Jul 9 14:53:49 2013 +0200 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Jul 10 14:27:31 2013 +0000 modern .ui widgetlayout for mailconfigpage Change-Id: I1e7dae74e20f9133f3c4f6319bc294ea5bec22f6 Reviewed-on: https://gerrit.libreoffice.org/4783 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
So I just encountered port fields in Firefox proxy settings and Ubuntu network settings, and they're all spin buttons. Maybe this is NOTABUG?
(In reply to Aron Budea from comment #6) > So I just encountered port fields in Firefox proxy settings and Ubuntu > network settings, and they're all spin buttons. Maybe this is NOTABUG? Adding UX team for the final decision. I think we can live with it if we just leave it...
Wrote on the KDE HIG: * Use spin boxes for numerical input only. Use a list or option menu when you need the user to select from fixed data sets of other types. * Use a spin box if the numerical value is meaningful or useful for the user to know, and the valid input range is unlimited or fixed at one end only. For example, a control for specifying the number of iterations of some action, or a time-out value. * If the range is fixed at both ends, or the numerical values are arbitrary (for example, a volume control), use a Slider control instead. * For cases where the values are constrained at both ends and there large ranges of integers (more than about 20) or floating-point values that require precise control, consider providing both a Slider and Spin Box. This allows the user to quickly set or fine-tune the setting more easily than they could with the slider control alone. The pure edit is not better as it gives no clue about numerical and constrained input. So odd yes, but better than ordinary edit.
(In reply to Heiko Tietze from comment #8) > The pure edit is not better as it gives no clue about numerical and > constrained input. So odd yes, but better than ordinary edit. Considering a slider wouldn't be useful in this case, let's close this as NOTABUG.