I am just seeing if anyone finds value with that brush size multiplier. Right now, you have an option to change it to 1x, 10x, and 100x in the brush editor. I don't think we really need that and it over-complicates changing brush sizes. I made the change in my branch to remove the multiplier and make the scale to be more exponential. Any opinions?

Well we had the exponential one before and it got turned into this one. I proposed to remove it before, but in the discussion it was pointed out that addional accurancy is required and so it stayed.

Can you point me to the discussion? I don't see what use case exists to need a brush under 1px. I have never seen another application use that, so I curious to why it would be required.

The discussion was on IRC, so I don't have a reference to it. Animtim can explain it better, I think.

I sent Timothee a message and this was his response.

I don't remember actually this discussion on irc.. I'd say the way it is now can be useful to set precise values by clicking on the slider.. at "x100", it can be hard to click on the right value or even close to it for small brushes, specially around less than 10px.. From a personal point of view, I'd be fine without it as most of the time I use resize-on-canvas shortcut, or the top-toolbar size slider.. or if I need a precise value I type directly.. but when I think about people using a tablet-pc or similar setup they have only stylus as input, so it can probably be useful in such case.

It looks like his main concern is when going from 0-1000. It is difficult to pick smaller brush sizes. If we use a linear scale this is true, but using the exponential scale for the slider, I think it is pretty manageable picking smaller brush sizes.

I think we can remove the multiplier and go back to the slider (I already have the code in my branch). Boud was asking about this in my branch, so i thought I better get some more feedback on it. I will let him know it is ok. We can always change it if we learn of something else.

Might be a good idea to have an option in the settings to switch between both modes. Default would be the simple one.

are you finding a good use for needing the multiplier? One of the reasons that I don't like it is that it really constrains what you can do by default. With the multiplier, it makes the slider less useful.

1. 1x - almost useless since it only goes to 1
2. 10x - mostly useful for line work since it only goes to 10
3. 100x - mostly useful for large brushes since it is hard to select numbers below 10

If you want to create some type of setting that would add the multiplier, I would be ok with that compromise. It should not have a multiplier by default though. We still haven't come up with a good use case for why you need the multiplier. I don't like creating options if there isn't a good reason why people would use it. No other application seem to have a multiplier, so it is hard to imagine that Krita is solving a new problem that hasn't been seen before.

If someone really wants an exact number, they can just select the slider and type the number manually (maybe people don't know you can do that).

Just my thoughts.

I never was really happy with the multiplier myself, interestingly enough we don't have it in the toolbar size slider. I'm wondering why the right-click and numerical editing isn't enough for precision.

boudewijn wrote:I never was really happy with the multiplier myself, interestingly enough we don't have it in the toolbar size slider. I'm wondering why the right-click and numerical editing isn't enough for precision.

That's very easy: Nobody knows it exists. I went for a year of using Krita until Animtim told me.

Most software do double-clicking for this. Now, I personally think Krita's way is better, it's just undiscoverable. Maybe we should have a tool-tip for it?

I set up this page for the extreme basics of Krita that can't be found easily: https://userbase.kde.org/Krita/Manual/Interface, but ideally we'd make it more discoverable.

I already have it removed in my branch. I think we should just go for it. We can always revisit this if we find out something new we aren't aware of.

Yes... I guess it's time to put the diff of your branch to master up on reviewboard, so everyone can take a look at the diff & then when you get a ship it, it's time to merge to master

ok, I can put it on the reviewboard (https://git.reviewboard.kde.org/r/). I have a few miscellaneous UI changes in that branch. Who actually looks at the reviewboard? How is that different than just getting feedback through the forums?

I learned something about the right-click. Here, I did this with holding 'Shift' hover the field entry ( it works after clicking a first time in the field randomly ). I'm totally ok with removing the brush size multiplier in the brush edit panel.

scottpetrovic wrote:ok, I can put it on the reviewboard (https://git.reviewboard.kde.org/r/). I have a few miscellaneous UI changes in that branch. Who actually looks at the reviewboard? How is that different than just getting feedback through the forums?

You can specify groups and people that need to look at it. So for example, for my changes to the colour selectors, I added group 'calligra' and then added boudewijn, dmitry and slangkamp to the specific people field because these are the most active Krita developers. They then get a mail with the changes.

Specifically, why reviewboard is good is because it allows side-by-side comparison of the changes you made.
This allows checking for coding style, whether or not you remembered to add licenses, whether you implementation may cause problems, or just plain easier manners of handling a bit of code.
Added to that it allows boudewijn, for example, to go to a specific line and add commentary to it.

Here's an example with the color slider docker: https://git.reviewboard.kde.org/r/119183/
Dmitry spotted that I could've done some changes to how the preferences were loaded, as well as that my coding style was messy. So I fixed those, and then it could go into master.

It's not just about getting working features, but also training each other and keeping the code sensible.

@TheraHedwig - I love it! I am still starting out with the code base, so there is a lot I don't know. I will submit a diff and outline all of the different UI changes that I am proposing.