Description: Working with LibO 6.1 and the kde4 vcl, the +/- buttons in the position and size dialog work by adding/subtracting a fixed quantity while approximating up/down to a round value. For instance, with metric units (mm): value at 22.38, press +, get to 22.50, press + get to 23.00 In LibO 6.2 with the gtk3 vcl, the rounding is gone: value at 22.38, press + get to 22.88, etc. The rounding made it extra speedy to obtain grid alignment, so it is a pity to see it gone. Steps to Reproduce: See description Actual Results: See description Expected Results: See description Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Thanks for reporting this issue. Could you please try to reproduce it with the version 6.2.2.2 of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Issue is also in 6.2.2.2. Note that it may be present also in 6.1.x, but I cannot test there and I cannot base on my memory since I have always used 6.1.x only with the kde4 vcl
Ok, the behaviour is different in sidebar vs. the dialog. With kf5 & gen vcl backends, both the dialog and sidebar round 22,38 mm -> 22,50 Arch Linux 64-bit Version: 6.4.0.0.alpha0+ Build ID: b9a776837462eeb6d50d0decc42604c0c3008eb1 CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 11 August 2019
Created attachment 153435 [details] standalone gtk .ui A standalone native gtk example, run with glade-previewer -f gtk-spinbutton.ui
Created attachment 153436 [details] same, but with snap-to-ticks enabled glade-previewer -f gtk-spinbutton-snap-to-ticks.ui
WONTFIX is a bit misleading, CANTFIX in the sense that there isn't a way to do it with the native GtkSpinButton that I can see. There is snap-to-ticks as shown in that second .ui example, but that will do the snap for directly typed user input as well. The distinction from values entered in the entry vs values entered by up/down doesn't exist.
Can the issue be passed upstream to the GTK toolkit developers as an enhancement request, then?