New feature for review

[Boudewijn Rempt]

On Monday 02 November 2009, LukasT.dev at gmail.com wrote:
> On Monday 02 November 2009 13:44:07 Cyrille Berger wrote:

> > The problem is that in your patch nothing is abstracted. It introduces a
> > "changeBrushSize", and if I remember well the design of the paint op, we
> > wanted to hide the idea of "brush", and I think your patch go one step
> >  back. You are right that it gives some flexibility to freehand tool on
> >  what input affect the brush size, yet the freehand tool is not supposed
> > to know about brush. But then if we have other on canvas setting we want
> > to make we would have to extend KisPaintOpSettings to support more of
> > those settings (actually we already have a similar setting that allow to
> > set the offset of the duplicate op).
> 
> So let's rename it to changePaintopSize and you hide the idea of the
>  "brush"

I would like something like this:

 * actuators: keyboard shortcuts, wheel (with delta), pressure, special ways 
of moving the cursor.
 * those are associated with (aspects of) a paintop option and shown in a 
combobox in the gui, like in photoshop 7. The association of an actuator and 
an option is not exclusive, so mouse wheel might actuate changes in both size 
and jitter, for instance.
 * KisTool would be responsible for sending the actuator signals to the active 
paintop

Interaction question: are changes made in this way sticky? I.e., would they 
change the preset, or would they change a local copy of the preset settings in 
the paintop, and be forgotten when we switch to a new paint?

However, this scheme needs quite a bit of coding -- I once started on it, but 
had to stop because there were other, more pressing issues.

I'm also considering whether we shouldn't have _two_ paintop settings widgets: 
the big one with all the options in the dropdown, and a smaller one that fits 
in the toolbar with the most useful options for every paintop.

In the end, I think we really need to do some serious interaction design here 
instead of muddling one change on top of another.

> Freehand now controls the brush outline. You can't turn on and off the
> outline in the paintop settings. That's another reason I would put it in
> the freehand tool.

Do we want that? I think that the cursor type should stay some global setting.

> > So on one hand we might not want to have the KisPaintOpSettings to know
> >  about events (this would go in the direction of separating UI of
> >  painting), and we probably do not want to bloat the KisPaintOpSettings
> >  with settings that are specific to a set of paintops.
> 
> The biggest problem I see is the conversion of the various measures like
> pixels in documents vs pixels in widget + zoom + points + another
> complication. If this is in KisPaintOpSettings , it drags flake in and
>  that's something boud was trying to avoid (there is bug report about it)

Paintops should only work in pixel sizes and not be concerned about converting 
from document to view.

> My feature plan for 2.2 also contains brush outlines.
> I would love to see paintops to work just in document measures and the tool
> should handle the conversions. Current brush outline code breaks this.

Yes, exactly.

>  Maybe we should talk this in Oslo and design something more abstract.

Ok.

> > So maybe what we need is a new class "Editor", that would be triggered by
> > paint tools when the user press shift, that would countains a set of
> >  hanles, be able to draw an overlay (not so good for UI seperation
> > though), and list actions (that can be assigned to keyboard).
> > With the handles you could change the size of the brush, set the
> > position/offset for the duplicate op. Overlay would fix the visualisation
> >  issue for when the user do not use the outline. And finaly action could
> >  countains stuff like "increase brush size" that could be mapped to a
> >  shortcut.
> >
> > Just an idea :)
> 
> At least I would like to see this patch in 2.2 if there is nobody working
>  on something better. But we also want to stabilize our API so it can
>  contradict.
> 
> boud, your opinion?

I'm fine with committing this for now and working towards a real solution 
afterwards. It helps our users right now.

-- 
Boudewijn Rempt | http://www.valdyas.org