Bug 124422 - With Impress/Draw 6.2 and gtk3 vcl +/- buttons in position and size dialog have usability regressions
Summary: With Impress/Draw 6.2 and gtk3 vcl +/- buttons in position and size dialog ha...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All Linux (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2019-03-29 10:19 UTC by Callegar
Modified: 2019-08-16 14:41 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
standalone gtk .ui (2.61 KB, application/x-designer)
2019-08-16 09:53 UTC, Caolán McNamara
Details
same, but with snap-to-ticks enabled (2.67 KB, application/x-designer)
2019-08-16 09:57 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2019-03-29 10:19:36 UTC
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
Comment 1 Xisco Faulí 2019-03-29 15:20:33 UTC
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.
Comment 2 Callegar 2019-03-29 20:53:43 UTC
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
Comment 3 Buovjaga 2019-08-14 16:16:46 UTC
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
Comment 4 Caolán McNamara 2019-08-16 09:53:46 UTC
Created attachment 153435 [details]
standalone gtk .ui

A standalone native gtk example, run with

glade-previewer -f gtk-spinbutton.ui
Comment 5 Caolán McNamara 2019-08-16 09:57:51 UTC
Created attachment 153436 [details]
same, but with snap-to-ticks enabled

glade-previewer -f gtk-spinbutton-snap-to-ticks.ui
Comment 6 Caolán McNamara 2019-08-16 14:13:34 UTC
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.
Comment 7 Callegar 2019-08-16 14:41:06 UTC
Can the issue be passed upstream to the GTK toolkit developers as an enhancement request, then?