radio button control for grid size (sketcher)

[hinckel]

The radio button control for grid size control has an inconsistent behavior
1. Advances are in 1 mm step independently of the current size.
2. When scrolling down from 1 mm the value of grid size jumps down to 0.001 mm
3. When setting the current value to 1 m (1000 mm) scrolling up and down it will change by values of 1 mm (999 mm 0r 1001 mm)

Suggestion
A more convenient behavior would be that the scrolling step be aware of the current grid size. For example, for current value between
1 mm and 10 mm the scrolling step is 1 mm. Between 10 mm and 100 mm the scrolling step is 10 mm, usw..

With this change, when scrolling down from 1 mm de next value down would be 0.9 mm and not 0.001 mm

[NormandC]

How is that relevant to the Assembly workbench, which has yet to be included in master? You do realize you posted in the Assembly forum, do you?

[jmaustpc]

The radio button control for grid size control has an inconsistent behavior

It sounds like you are talking about the one in the Taskview.

in the property editor it will allow the grid size to be negative.

OS: Ubuntu 12.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6523 (Git)
Build type: Release
Branch: master
Hash: ecd6517cb00fcf05edd41a38b3ce1fa8b16ec3ad
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 3.1.3
OCC version: 6.9.1.oce-0.18-dev

[wmayer]

1. Advances are in 1 mm step independently of the current size.
2. When scrolling down from 1 mm the value of grid size jumps down to 0.001 mm
3. When setting the current value to 1 m (1000 mm) scrolling up and down it will change by values of 1 mm (999 mm 0r 1001 mm)

But that's standard behaviour of all Qt spin boxes. Trying to make an adaptive step size can be very tricky.

[Fat-Zer]

But that's standard behaviour of all Qt spin boxes. Trying to make an adaptive step size can be very tricky.

not really, it's QuantitySpinBox and it should be enough to slightly alter the stepBy()...

[piffpoof]

The radio button control for grid size control has an inconsistent behavior
1. Advances are in 1 mm step independently of the current size.
2. When scrolling down from 1 mm the value of grid size jumps down to 0.001 mm
3. When setting the current value to 1 m (1000 mm) scrolling up and down it will change by values of 1 mm (999 mm 0r 1001 mm)

Suggestion
A more convenient behavior would be that the scrolling step be aware of the current grid size. For example, for current value between
1 mm and 10 mm the scrolling step is 1 mm. Between 10 mm and 100 mm the scrolling step is 10 mm, usw..

With this change, when scrolling down from 1 mm de next value down would be 0.9 mm and not 0.001 mm

hi
I'm not trying to go "off topic", but I've been building a list of FreeCAD behaviours that I don't find intuitive. I don't want to call them bugs, although some of them might be. At present I really just view them as anomalous behaviours.

I've put together a list of them at FreeCAD GUI for Data Manipulation. The name may not be the best, but I wasn't sure what else to call it.

Specifically Issue#7 seems to exhibit similar behaviour as is referred to in this thread. In compiling my list I was wondering if the behaviours I listed were somehow linked in the software as they all revolve around data input via the GUI.

I have never posted the list as I have never been sure where to post it, the list needs more work before anything can be classed a bug.

Dean

[NormandC]

FYI there was a topic about usability a long time ago, you may want to search for it (good luck). At the time the devs acknowledged that there were inconsistencies in the GUI and that was due to the way people get involved in the project, there is no centralized authority nor rigidly structured development plan. jriegel admitted that at some point it would need to be addressed but it would have to be a concerted effort.