On Mon, 2017-12-04 at 14:43 +0100, Eduard Braun wrote:
Hi Tav,
thanks for looking into this!
One question to get on the same page:
This is about sliders like "Blur" and "Opacity" (which are re-
used
in some other places, too), right? However the actual color
sliders in the Fill and Stroke dialog are not affected?
Yes...
Some thoughts from my side:
The "top part" dragging is very useful, we should have that.
The "bottom part" dragging never felt quite right for me and
was
actually very confusing when I first started using Inkscape,
so
personally I'd be fine with dropping that.
OK. That should be easy to do.
Having text and the spinner inside the widget is nice as it
saves a lot of space and creates a clean UI control that is
immediately recognizable as such (in contrast to multiple
controls loosely packed into a box with each other).
If it's implementable with reasonable effort it's probably
good
to keep it, especially for locations where there is not much
room for an additional label and spinner (e.g. in the toolbar
of
the various tools that use the widget).
It's not too hard (already done in my toy implementation).
The previous bullet point is only true if it's done right
-
thanks to gtk3's wasteful use of screen space I'd consider
most
spinners in the toolbar broken right now (the label is
usually
hidden behind an ellipsis; due to the two huge buttons which
are
now placed side-by-side the usable width decreases even more,
so
we either need a more economic solution or need to rethink
the
use of spin sliders in the toolbar fundamentally.
One can narrow the +/- buttons via CSS ( ,up, .down { padding:0; } ).
I'll probably check this in (actually I'll probably set it to 2px,
default is 8px).
One performance consideration that might be worth to
have in mind when doing the rewrite:
For some reason the custom spinner widget has
a much worse redraw performance than other spinner
implementations (e.g. the ones in the color selector):
If I change opacity of an object the widget
only updates a few times per second and is redrawn with a
delay (canvas reflects the current value properly though).
In
contrast if I change the fill opacity of the same object
this
spinner widget redraws without noticeable delay.
(strike that part - it only seems to affect the gtk2 build
and I
assume you won't backport this to 0.92.x)
No, I won't be touching 0.92.x with this.
TLDR: I kind of like the spin sliders like they are now for
"Blur"/"Opacity" (and could do without the bottom part
sliding),
however they waste too much space to be useful in toolbars
right
now.
Best Regards,
Eduard
Am 04.12.2017 um 13:42 schrieb Tavmjong
Bah:
> Hi,
>
> I've been looking into replacing the Gimp Spin Slider widget (e.g
> Blur/Opacity in the Fill and Stroke dialog). The widget is licensed
> under GPLv3 and is the only reason Inkscape as a whole is licensed
> under GPLv3 rather GPLv2.. The board sometime ago agree that being
> a
> GPLv2 program was desirable (I don't remember the exact reasoning).
>
> A normal Gtk Spin Slider (aka Gtk::SpinButton) has an option to
> show
> the "progress" of slider, that is the percentage (defined in some
> arbitrary way) between a minimum and maximum value. This in Gtk 2
> is
> shown as a solid blue bar with width proportional to the value that
> covers the widget from top to bottom. In Gtk 3 the solid blue bar
> is
> replaced by a thin blue bar at the bottom of the widget.
>
> As far as I can tell, the Gimp version of the slider makes three
> changes:
>
> 1. It allows for a label inside the widget. This is a nice space
> saving
> feature. The widget handles changing the label text from black to
> white
> as the progress bar moves across the label.
>
> 2. It allows for a non-uniform scale by adding a "gamma" factor.
>
> 3. It adds the ability to drag the progress bar to change the
> value. If
> one drags from the top (down arrow cursor) the change follows the
> cursor directly. If one drags along the bottom half (double headed
> cursor) the change is finer and relative to the current value.
>
> I've always found that dragging the progress bar to be a bit
> awkward.
> One problem is that one can not start the drag at the far right of
> the
> widget as that area is reserved for typing a value directly in.
> Also,
> the different functionality of starting the drag in the top of the
> widget vs. the bottom of the widget is confusing.
>
> Since I am rewriting this widget, I can adjust it to what people
> want:
>
> * Do you want the progress bar?
>
> * If so, should it be the full height of the widget (quite a bit
> more
> complicated)?
>
> * Do you want to be able to drag the bar? With one/two methods?
>
> * Any other changes?
>
> Thanks,
>
> Tav
>
>
>
>
>
>
>
>
> -----------------------------------------------------------------
> -------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites,
Slashdot.org!
http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>