Hello,
Revision 10103 adds horizontal sliders to the Int and Float extension widgets in order to make parameters a bit easier to handle. It perfectly fits large numbers (colors or angles related values) but may be less efficient with small range parameters (as in the SVG calendar extension). Thus I've implemented two modes (mimicking the radiobutton parameter), full (default, with slider) and minimal (no slider) that can be used by adding an appearance="<mode>" attribute to the int or float element in the inx file or internal extension structure. The size of the slider is the same for all widgets, 200px (about the same as the sliders used in Gimp). Please test and comment!
Regards, -- Nicolas
On 14/3/11 18:10, Nicolas Dufour wrote:
Revision 10103 adds horizontal sliders to the Int and Float extension widgets in order to make parameters a bit easier to handle. It perfectly fits large numbers (colors or angles related values) but may be less efficient with small range parameters (as in the SVG calendar extension). Thus I've implemented two modes (mimicking the radiobutton parameter), full (default, with slider) and minimal (no slider) that can be used by adding an appearance="<mode>" attribute to the int or float element in the inx file or internal extension structure. The size of the slider is the same for all widgets, 200px (about the same as the sliders used in Gimp). Please test and comment!
Just picked a few random extensions to test - e.g. 'Generate from Path > Pattern along path': the lower and upper limits of the sliders for 'Space between copies', or 'Normal offset', are so big, that the sliders are not very useful unless you work with huge dimensions.
First impression: the sliders should not be the default mode, but only used when lower and upper bounds are carefully set and the slider is actually useful for the specific option [1].
It tends to widen all dialogs quite a lot when a (verbose) label, slider and spinbox are aligned in one row and the slider has a fixed width.
Also, it does change the default for contributed, externally hosted extensions, without their authors being aware or able to easily modify / updated already installed extensions. IMHO it would be preferable to add a new widget or mode, instead of redefining an existing one.
Other than that, I think it's great to have enhanced options for parameter input - thx for your continuing work to improve usability of the extension dialogs :)
~suv
[1] e.g. I'm not sure if a slider for the resolution of rasterization (dpi) when exporting to PDF makes sense - isn't this a value one normally enters precise numbers?
Thanks for your comments.
De : ~suv <suv-sf@...58...>
First impression: the sliders should not be the default mode, but only used when lower and upper bounds are carefully set and the slider is actually useful for the specific option [1].
I mainly tested the sliders with filters, where they are useful almost everywhere. But it seems that it's the opposite with extensions.
It tends to widen all dialogs quite a lot when a (verbose) label, slider and spinbox are aligned in one row and the slider has a fixed width.
Yes, but 200px is IMHO a good compromise. We could also add another mode for small sliders (let's say 100px), but I'd rather keep the options number as small as possible. Of course it's possible to disable (or not enable) sliders when the dialog is too wide.
Also, it does change the default for contributed, externally hosted extensions, without their authors being aware or able to easily modify / updated already installed extensions. IMHO it would be preferable to add a new widget or mode, instead of redefining an existing one.
That's the main argument against the sliders as default option. But since no extension uses the appearance="full" attribute ATM, I'll first modify the filters to work with sliders, and then revert the default to minimal so that the existing extensions stay unchanged.
Regards. -- Nicolas
That's the main argument against the sliders as default option. But since no extension uses the appearance="full" attribute ATM, I'll first modify the filters to work with sliders, and then revert the default to minimal so that the
existing extensions stay unchanged.
Default mode modifications committed in the trunk, revision 10106. -- Nicolas
FWIW I'd like to ask if this helps with the accuracy issue. Specifically I find that numbers only get one decimal point in the spinner control for floats. I.e. The spinner cannot get me 1.35, 1.36 it can only get me 1.3, 1.4 Also sometimes the returned value for 0 is not 0 exactly. So I need to add a check for if val< 0.01: val = 0 so the rest of my code works properly if a 0 value means a change in behaviour. (e.g. roundness of a border = 0 implies use a rect instead of a nice curve.)
my 2 cents...MarkS...
On 3/16/2011 6:25 AM, Nicolas Dufour wrote:
That's the main argument against the sliders as default option. But since no extension uses the appearance="full" attribute ATM, I'll first modify the filters to work with sliders, and then revert the default to minimal so that the
existing extensions stay unchanged.
Default mode modifications committed in the trunk, revision 10106.
Nicolas
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Mark,
De : Mark Schafer <mschafer@...2596...> FWIW I'd like to ask if this helps with the accuracy issue. Specifically I find that numbers only get one decimal point in the spinner control for floats. I.e. The spinner cannot get me 1.35, 1.36 it can only get me 1.3, 1.4 Also sometimes the returned value for 0 is not 0 exactly. So I need to add a check for if val< 0.01: val = 0 so the rest of my code works properly if a 0 value means a change in behaviour. (e.g. roundness of a border = 0 implies use a rect instead of a nice curve.)
You can set the precision attribute in the float and integer elements (INX file). The default value is 1, but you can set it to 2 if you want two digits after the point.
Example: <param name="prec1" type="float" gui-text="precision1:">2.35</param> --> 2.3 <param name="prec2" type="float" precision="2" gui-text="precision2:">2.35</param> --> 2.35
Note that the precision attribute doesn't change the spinner and mouse increment step (still 0.1).
Regards. -- Nicolas
participants (3)
-
Mark Schafer -
Nicolas Dufour -
~suv