spin boxes increment values on filters UI need tweaking before 0.46 release

I agree with you. Thank you for your suggestion. It will be reviewed before the release. In my opinition the blur slider needs some attention too.

Thanks for identifying where some improvements could be added. Could you please indicate what increments should be set for each of the spinners in feTurbulence (and any other filters).

[spinners are set src/ui/dialog/filter-effects-dialog.cpp]

Ping?

We're running low on time for implementing this, although I believe it will be a reasonably low-risk change.

I must have slept the last days. I will see, what i can do to those spinners. Thank you for the pointing to the right place in the code, Bryce.

Okay, i could do nothing with the source, so i will just write, what i think should be done.

I only reviewed the blur slider. It should probably be made logarithmic or at least pseudo logarithmic.

The maximum blur should be 40 %. That's enough to manage with the slider. If someone needs more, he can type it in the textfield.

The steps under 1% are needed oftentimes to make a glow effect.

0.1 - 0.2 - 0.3 - 0.4 - 0.5 - 0.6 - 0.7

Then you need steps under 10% to make general blurryness.

1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9

The steps above nine are less important, so a stepping of 10 units is enough.

10 - 20 - 30 - 40%

To indicate on the slider, that it is nonlinear it would be good to have a scale under it, which at least indicates the edges. e.g. 0.1- 0.3 - 0.7 - 1 - 5 - 10 - 40

If you need, i could probably make a mockup picture of this proposed slider.

Thanks for the feedback on this, however I'm still sketchy on exactly what changes to make to achieve what you've described. A mockup would almost certainly help, however I think maybe it'd be better if I explained to you how to make the change since the coding is fairly straightforward, and since then you could take time to experiment around and get it exactly as you feel best.

In filter-effects-dialog.cpp, in function FilterEffectsDialog::init_settings_widgets(), single and dual "spin sliders" are created by the function calls add_spinslider() and add_dualspinslider(). You'll see a whole mess of these which add all the parameter controls. For example, here's the code to add the dual spin slider for Gaussian Blur's control:

    _settings->type(NR_FILTER_GAUSSIANBLUR);
    _settings->add_dualspinslider(SP_ATTR_STDDEVIATION, _("Standard Deviation"), 0.01, 100, 1, 0.01, 1);

So those 5 numbers in the function parameters are what controls the steps and stuff. The arguments are low, high, step increment, climb, and digits, in order respectively. Low and high are the minimum and maximum allowed values for the control. Step increment is how much the spinner increments each time you click on an up or down button. Climb rate is the acceleration rate when holding down a button. Digits is the precision (number of digits after the decimal point.)

add_spinslider() has the same five arguments at the end of its list.

So basically, tweak the numbers to what you think they should be, recompile, test, repeat. :-)

I'm not sure about if the sliders can be made logarithmic... I suspect that'd be a more involved coding task, but maybe the controls can be made to work well enough without.

vonHalenbach, I hope this is enough info to get you going; if not just drop me an email and I'll be happy to answer questions. When you get something you're reasonably happy with, do the command `svn diff > spinners.patch`, upload it to this bug and ping me, and I'll give it a review and apply it.

I very much sympatize the idea of a log slider. Values above 35-40% for std deviation in feGaussian are rarely useful and do not require as much precision as numbers below 5% do.

I've played with the controls a bit myself and it seems like in this particular case no simple tweaking would be adequate since it would not allow for the desired non-linear behaviour. This might in turn require a new custom control.

For some implementation ideas, take a look at the code in
desktop-widget.cpp that controls the zoom_status spinbutton. This
implements logarithmic scaling by setting the spinbutton's value to
the *log* of the requested zoom. Linear increments/decrements in this
value then result in multiplicative scaling of the zoom factor. There
is some code in zoom_output and zoom_input that takes care of
converting from the log value to the true zoom value (which is
displayed).

Thanks Tom, this is the obvious way to do it and the solution I have already initially drafted. I just need to get up to speed with GTK, but this should not be a problem. I will try.

mfloryan, cool thanks for taking a shot at this; let us know how it comes along.

Meantime, since it sounds like resolving this requires development work beyond just tweaking the increment values, I don't think it's something we can expect to do for the 0.46 release, so I've removed the milestone. Please work on it at your convenience and upload for the 0.47 development branch (or post to this bug) as you feel ready. :-)

I've just spoken with GIMP developers at #gimp and they say it has a funciton called "gimp_scale_entry_set_logarithmic()". Could we please borrow it?

gimp_scale_entry_set_logarithmic() is still available in Gimp 2.8, in libgimpwidgets/gimpscaleentry.c.