X and Y values for Watermark are too coarse

[RawConvert]

Previously Watermark supported values with 3 decimal places and this made it possible to locate the watermark (I'm using Simple Text) accurately. E.g. putting your name in the corner of an image.
Recently it has changed and only 2 dec places are now used. This makes it impossible to put the text exactly where you want. Right-clicking the X or Y values allows 3 dec places to be entered, but the value is then rounded to 2 places.
Please could we return to the previous functionality.

Master 3.1.0+2440g673f25287-dirty 2 dec places
Master 3.1.0+2017ga6c18e1b7-dirty (around 9 June) 3 dec places

Ubuntu 18.04

[dterrahe]

Please check if this was fixed by #5721, thanks.

[jade-nl]

@dterrahe : Are you sure you mean #5721?

I'm asking because:
a) This (quickfix) doesn't solve the problem,
b) It would be a 4 day old fixed and merged issue for a <1 day old problem.

[dterrahe]

Hi @jade-nl
The bug was reported against 673f252 and it looks to me like the fixes in #5721, which definitely were meant to address this issue, were merged after that. But if you have tested current master and the problem still exists then I'll have a look when i get back home. Please confirm. Thanks!

[jade-nl]

I checked both current master and, to make sure, cloned/build it from your fork/branch.

Both still show this issue: increments are 0.010 instead of the previous 0.001 (for both X and Y) when using the mouse wheel.

[dterrahe]

Including when holding ctrl? The bug is about rounding to two digits even when entered manually. I think that should work now.

To me a step of 0.01 that can be decreased (by holding ctrl) makes more sense than 0.001 (and ctrl not having any effect).

It has already been agreed with @TurboGit to revisit these defaults after 3.2

[RawConvert]

@dterrahe , pls note, holding ctrl is no help here. I have the option set in preferences to scroll the modules on the right, which I think is extremely useful. But when using the wheel to scroll the modules, using CTRL+WHEEL just carries on scrolling modules. So all that's available is CTRL+ALT+Wheel, which gives .01 increments.
(I've raised previously why Ctrl doesn't do fine tuning in this situation - this aspect now covered by #4899)

[RawConvert]

@dterrahe , hi, please note, it's still 2 d.p. as originally reported. Just tested with dt 3.2.1 release.

[dterrahe]

There were two aspects to this bug report:

1. values were rounded to 2 digits instead of 3 as previously. This meant step size was now changed to 0.01 but also that achieving smaller changes by holding the ctrl key while scrolling or manually entering a value with a 3rd digit would not work, because it would be rounded to 2 digits anyway. This problem was resolved by Restore slider digits where lost in introspection changes #5721,

2. step size is now 0.01 where it was 0.001 before. I consider this an improvement because smaller changes can be achieved by holding ctrl and it would be suboptimal to everywhere set all step sizes to the minimum. So I don't intend to change it, but you can submit a PR and argue for its inclusion.

Your #4899 separately raised that ctrl doesn't work for you. I believe I fixed this for you in #5755, but this required a larger change so @TurboGit deemed it too risky to include in 3.2 (and I would agree with that assessment). If you had wanted it included in 3.2, you could have lobbied for that and helped with testing.

All the information I have repeated here is easily available in the comments in this issue or by following the links.

[RawConvert]

I've just had another look and can see that by manually entering a value, 3 decimal places are supported, so thanks for that. (The scroll remains at .01 step of course, but retains any 3rd dec place entered manually, fine).

I think .01 step is fine as long as the CTRL fine tune is available. Do you think #4899 will be looked at now that 3.2 is released? I'm happy to do some testing.

[dterrahe]

Now that 3.2.1 is out the door, there are quite a few PRs for @TurboGit to look at so it is up to him to assign properties.

But it would definitely be helpful if you tested the PR as well so that, if you find it doesn't solve your problem or causes other issues, I could address those before Pascal looks at it. Having to go round twice would potentially cause a longer delay by going to the back of the queue.

[RawConvert]

Seems a good plan. I'm putting some comments on #4899.

[RawConvert]

I see this is now fixed in master 3.3.0 23Aug20. ** Thank You **