I'd like to bring up an idea that does not seem too difficult to
implement and that should replace the unusuable slider widgets for, say,
brush size. If you are okay with that, I might implement it.
The sliders are virtually useless because they cover a fixed range from
0 to <insert big value here> without any intelligent behaviour. For the
brush size, for example, that means you can at best alter the brush size
in 20px steps with a reasonably big toolbox.
There have been some good suggestions on IRC already, how this could be
handled more intellegently. Coming from another software package which
has, that's at leat my opinion, one of the best interfaces that I've
ever seen, I want to port over one idea which has become quite popular
in contemporary software, that is, using the whole screen for adjusting
Usually, you can start dragging on the textfield (MMB) and drag all the
way over the screen while the size adjusts, if you hit the screen
border, your pointer is reset to the opposite border, so you can
practically keep dragging infinitely.
The problem with that kind of solution is, that it works in particularly
well with *relative* input devices, which are the most used for common
software. In order to achieve a similar intelligent solution for absolut
input devices, we need something else:
The central idea: You must be able to keep dragging infinitely.
The solution: See sketch attached
It looks complicated at first but to use it you don't really have to
understand the technical implementation. For the sake of clarity, a
little on-screen field appears, indicating the mode of operation, but
the principle works equally well without any indicator than the changing
value in the textbox and dragging blindly over the whole screen.
=> Dragging the pointer horizontally will increase or decrease the
=> Dragging the pointer vertically will increase or decrease the amount
by which the value changes when dragging horizontally
In colors above is the mathematical modelation for a quanified grip of
the principle. Notice that h(x) actually indicates the *change* of the
value - not the absolute value itsself.
For the implementation there are a few more details to mind (which, the
user doesn't have to worry about, becaue the operation itsself behaves
-> Which Point in the field will the cursor start in when starting to
-> How is the functional combination of what I called g(y) and h(x)? Is
a linear or non-linear function practical?
-> How are g(y) and h(x) scaled in particular - that should be most
likely be decided on a per-use basis.
-> If we choose a non-exponential form for g(y), the value of which
might drop below 0 (and thus invert the behaviour of horizontal
dragging), what should happen if the user drags below the 0-line?
An idea would be that the 0-line shifts accordingly.
-> Same question as above applies to h(x). Here it will most likely make
sense to have the 0-Assymptode shift accordingly as it will me the
most intuitive interaction (for values which per se can't drop below
a specified minimum)
And optional, separate idea: It would be great if the user could change
the specifications above (->) himself in a context menu. But that is
just nice to have.
Mathematical sidenote, if we choose a non linear form for either g(y) or
h(x), the curl of the vector field will increase to the left, hence
rotating at the left has a bigger effect - see examples:
A few examples of (very intuitive) operation:
* Increase a tiny bit: Drag downwards, drag left
* Increase a lot: Drag upwards, drag left
* Increase infinitely: Drag somewhere to the the left, drag circles CCW
* Decrease infinitely: Drag somewhere to the the left, drag circles CW
* Tediously increase very carefully, without limits: Like above, just at
the right instead of the left
The implementation of that is probably less lines than this email is
long. The complete algorithm can run isolated for the widget,
implementing the little overlay which shows navigation instructions is
most likely to be the most difficult thing to do and a piece of cake.
Gimp-developer mailing list