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 the value. 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 value => 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 intutionally): -> Which Point in the field will the cursor start in when starting to drag? -> 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. -- Cedric _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
