when working with increase/decrease brush size shortcuts at a certain point an increment of 1 jumps to an increment of 10 immediatly. This is quite annoying when painting details on a big image where a brush of 10-30 pixels is actually quite small and you still might need some minute control for your brush size. I feel this is quite a steep jump,and perhaps should be smaller. I suggest : fixed ,smaller increments ->first increase in ones to 10 ,in 2's to 20 or 30,then increase in 5's to 50 ,then increase in 10's and so on. (if you detect multiple presses in short bursts you could increase increments quicker)
I use the shortcut to increase / decrease the brush diameter all the time. As shift drag is extremely laggy in my setup. I don't agree at all with so much granularity. But probably setting a 5 number increment step between 10 and 40 would be fine. In my normal case usage I press X number of times to get to a bigger size, and I remember to press the same X number of times to get back to the previous size. About the last part you added --> "if you detect multiple presses in short bursts you could increase increments quicker" But I find a problem, how short should the time between keypress to be considered a burst an how long the time between press to be considered normal press. When I change sizes I always press quite rapidly. So for me setting a burst mode might not be productive as I would have to take care not only of Times the button was pressed but also remember the speed to control bursts. I think the shortcut is provided as a relative Sizing option. for finer control there is a slider. however as I commented earlier, a little tweak between 10 and 40 is welcomed.
the slider is of no help to me as it fails to be exact and I can't use it to have absolute control over a small increase. On my system they also have a bug and if I make 2 or more button presses on slider butttons they increase immediatly to 1000. (maximum) I ask for increments of 2 between as a sort of compromise for what krita does now. As when you land anywhere between 10 or 20 suddenly smaller increments are of only 1 till you reach 10 or remains 10 when you increase. THis is not reliable nor has the same amount of keyboard presses. So in effect we already have increments of 1 in certain circumstances,and while I find those of 1 more useful then increments of 2, I proposed 2 as a bridge between the increments of 1 in one direction,and increments of 10 in the other. Currently while decreasing the brush size this is a difference of up to 9 presses (but variable to 1) replaced with only 5 absolute presses in BOTH directions. This would make for an equal amount of presses in both directions and is a compromise between increments of 1 and increments of 10 1-10 ->1 (10 presses) (same) 10-20->2 (5 presses) (in stead of 1~9,variable) 20-40->5 (4 presses) (in stead of only 2) Could you accept this? (never mind the short increase idea,it was silly ^^ )
We should try the settings you propose, perhaps I find them better. As for your problem of "if I make 2 or more button presses on slider butttons they increase immediatly to 1000. (maximum)" I have the same bug as you when I press the slider buttons using the stylus.
now that you can go below a valu of 1 pixel,maybe brush size increase at that leverl should also be done in smaller steps up to 1 before increasing from there. if not ,when you return over 1 pixel you are left with 1.10, 2.10 ,3.10 and so on,which is a bit silly I feel
I made a wish in Nov, 2011 with a proposition to solve a similar issue on Bug 287008 I'm not for smaller increments. And with time, I could just be fully satisfied with extra steps between 10 to 50px diameters. Under 10 and above 50px the actual system works Ok for me. a proposition to show range between 0 to 50px diameter : ================================================= >> actual ( note the annoying big step after 10 ) : 0 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 20 - 30 - 40 - 50 - 60 - 70 >> new ( smoother progression after 10 ) : 0 - 1 - 2 - 3 - 4 - 5 - 7 - 9 - 10 - 13 - 15 - 18 - 20 - 23- 25 - 28 - 30 - 35 - 40 - 45 - 50 - 60 - 70
I wouldn't go as far as 50 but 40px as the upper limit for the new progression. Other than that I find the proposed new smaller increments attractive. One thing I notice is that while Krita is capable of brush sizes of 2.30 1.457777. Does anyone actually uses/sets decimal points in brush sizes? At least I find them a bit annoying when they happen to appear.
I could accept the way deevad proposes this as well. As long as the SAME amount of presses is done in both directions. (which is not always the case currently,between 10 and 20) 6 and 8 seem to be missing,tho,I assume it's a mistake as you professed to be glad with the increments under 10 and what about the increments below 1? Do you agree if this indeed happens it should go up again in an even fashion? (SAME amount of presses in both ways!)
MANY years ago i found a workaround in Photoshop (this would have been PS7, probably, i'm only at CS2 now) --- i've changed computers and lost\forgotten the workaround. It was a two-key combo, and i think i assigned it somewhere, but memory fails. Familiar to anyone? I agree on incrementality. Make it like nudge. [ & ] change by 1 pixel, Shift+[ \ ] ((aka "{ and }")) change by 10s.
That should work, I guess... Maybe something we can discuss this weekend, at the sprint in Deventer.
Git commit 5997e439bd5166409d7edd84d4b7ad284c959225 by Dmitry Kazakov. Committed on 19/05/2014 at 14:27. Pushed by dkazakov into branch 'master'. Make changing the brush size with the shortcuts more consistent M +38 -14 krita/ui/tool/kis_tool_paint.cc M +3 -0 krita/ui/tool/kis_tool_paint.h http://commits.kde.org/calligra/5997e439bd5166409d7edd84d4b7ad284c959225
Thanks Dmitry, I think your commit also resolve this old 2011 one : https://bugs.kde.org/show_bug.cgi?id=287008 * one stone, two birds *
Solved There was a bug ,briefly,but it seems solved again