[Gimp-developer] New adjustment widgets
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
I'd like to add a PS addressing all mouse-only users who might read this: I'm aware that dragging circles with the mouse can be tedious and hence, of course, the principle of wrapping over at the screen border is still in. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
Sorry for the confusion. The attachment I tried submitting is too big and awaits moderation, hence I'm going to resend a smaller version so you can see at least something. Again, sorry, I messed up attachment: Untitled.jpg___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
On Fri, Jan 7, 2011 at 5:06 AM, Cedric Sodhi man...@gmx.net wrote: Sorry for the confusion. The attachment I tried submitting is too big and awaits moderation, hence I'm going to resend a smaller version so you can see at least something. Why don't you post your other attachment on the web somewhere to avoid the list restrictions? Mike ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
Cedric Sodhi wrote: 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. I think I have something there for us that is more straightforward: two things actually: #1 is what I got the Krita guys to implement during a sprint of theirs that I attended, it was based on my work on #2 actually. It works for long sliders in dialog boxes, not for our tool options panels. say you got a slider going from 1 to 1000. then divide the slider range (in pixels) in 3 equal parts, so that each handles a decade: |-- 1–10 --|-- 10–100 --|-- 100–1000 --| within each third the increase/decrease of value is linear. the Krita guys love this system (hardcore tablet users, btw), but as I said: only for long sliders. #2 is where I developed the whole idea. I was working on tool options widgets that would allow the whole tool options dockable to be exactly 2 toolbox icons wide (normal icon size, the need for the small theme goes away a.f.a.t. toolbox is concerned): http://mmiworks.net/test/small.png top to bottom those are are 1 popup selection list, 4 sliders and two 'checkboxes' (on/off switches), in real 1-to-1 size. yes, cut off texts are shown fully on mouse-over: this is GIMP and usage is trained, so position; (part) identification and feedback (could better on the checkbox, I see now) are what count. you can see here where the current experimental sliders in git come from. Krite did their #1 sliders in this form, but not the following: so how are these tiny sliders going to work? well click the mouse button down on the slider (not on the number) and this pops up: http://mmiworks.net/test/decadepopup.png with the current value right under the mouse position, so releasing in panic does not change the slider value. moving vertically you switch decades, horizontally everything is linear within a decade. one could easily add decades, having a range factor of a million for instance (e.g. 0.01–1) when that is needed. grocking is simple, motions (up/down, left/right) are linear, feedback always there. is there a flaw? yes: popping up at the screen's edge, and wanting the 'value right under the mouse' to work. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
On Fri, 2011-01-07 at 12:55 +0100, peter sikking wrote: http://mmiworks.net/test/decadepopup.png Aside of differences in labeling (of course not unimportant), it's the same concept as http://www.sidefx.com/docs/houdini9.5/basics/ladder right? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
Thorsten Wilms wrote: On Fri, 2011-01-07 at 12:55 +0100, peter sikking wrote: http://mmiworks.net/test/decadepopup.png Aside of differences in labeling (of course not unimportant), it's the same concept as http://www.sidefx.com/docs/houdini9.5/basics/ladder right? vertically: yes, close enough horizontally: no (dragging in thin air?) single click popup, single move adjust: yes primitive text widget with no slider scale: no (just to be exact) --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On Thu, Jan 6, 2011 at 4:51 PM, Alexia Death alexiade...@gmail.com wrote: On Wednesday, January 05, 2011 19:42:28 sigetch wrote: I tried merging the smooth on top of the master yesterday. It works nicely, I'm very happy to hear that. has a little bit of room for improvement(like makining the line catch up when you stop or finish the stroke) I agree that improve of the stroke finishing process is very important. the circular queue thingy and the fact that it's a miniobject stuck into paint options object and its existence in general. The way it would need to be rewritten is adding a stroke array and its management functions into the paint core and then smoth from that. The smooth function also belongs in the paint core. I simply imitate the gimp_paint_options_get_gradient_color(...), but paint core is better choice to implement that function. And why does ink have its own circular buffer? whats wrong with using the paintcores one? Well, simply by the historical reason. I implemented the smoothing of the ink tool first, and then extend it to the brush core, while keeping the first one unchanged... And to discuss all of this, Id like to see you in IRC :) I'd like to do so, but unfortunately, I have very little spare time in this month, neither in the next month... X( -- sigetch. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
On 01/07/2011 03:55 AM, peter sikking wrote: snip say you got a slider going from 1 to 1000. then divide the slider range (in pixels) in 3 equal parts, so that each handles a decade: |-- 1–10 --|-- 10–100 --|-- 100–1000 --| within each third the increase/decrease of value is linear. This looks neat -- OTOH as tablets get more multitouch the current trend seems to be touch speed controls rate of change nonlinearly. Mouse tracking could execute this way. Looks hard, tho :-) -- Burnie ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
