how should selections work

[Boudewijn Rempt]

On Sunday 17 April 2005 20:24, Casper Boemann wrote:

> How do we visualise selections. For now I'll just call it "graying" but it
> should actually be more intelligent so that it is always visible that
> something is selected, nomatter what the selected area contains.

I like the current way of visualizing -- but I'd be the first to admit that I 
only started using this way of visualizing selections because I wasn't able 
to figure out how to do marching ants from a byte mask, let alone a _fast_ 
marching ants.

What I'd want, ideally, is a mask but with a thin, contrasting line (either 
white or black depending on the average value of the image) around the 
selected area. 

The colour of the selection mask is currently user-selectable, even though 
we've got a bug here that means that the colour is not persistent -- this 
should be easy to do when we've got the persistent selections you're working 
on.

>
> I guess we want to continue with the distinction between no selection and
> selection. When we have no specific selection everything should be visible.
> This is the normal work mode and the user should be able to see the
> masterpiece without any "graying"
>
> Now the user selects some specific area. Currently the "graying" is
> applied to all the underlying layers (actually the composition of them)
> wheras the layers on top are not "grayed". This is inconsistent.


Only the current layer's selection should be shown. This is a bug in our TODO. 
And, ideally, the selection should be rendered on top of the complete 
composited image. I rather though that was already true -- because of the 
code in renderToProjection, but maybe I'm wrong.

>
> How could we do this in a more intuitive way?
>
> 1) we could gray only the active layer. But the other layers are not
> touchable either, so that seems a bit inconsistent too.
>
> 2) we could gray all layers except the selected part of the active layer.
> It would be clearly visible to the user. but that would gray areas that are
> acutally touchable, but just hidden by a grayed layer on top.
>
> 3) we could apply the graying after all composition is made. Then it would
> be clearly visible where the layer is touchable and where it isn't. But the
> things you see non-grayed could actually belong to another layer.
>

That's the way I intended it for Krita 1.0 -- any divergence could be called a 
bug...

> other ideas or a preference ?
>
> The selected area should be normally visible, and non selected parts
> "grayed". Right ?

Yes. The invert button in the selection tools is meant to make it possible to 
show it the other way around -- which is useful when selecting by color. 
Doesn't work correctly yet, though.

>
> >From a programmers pov I think (but I'm not sure) that the statefulness of
> > the
>
> alpha strategy is a cause of problems. The color and inv flag should be
> moved to the KisSelection.
>

Note that the alpha strategy is not retrieved to a singleton; every selection 
has its own instance, so there's no interference possible. Moving the mask 
colour to the selection paint device makes rendering harder.

> To do that the colorstrategies must provide a way to apply a selection
> mask, so we don't have to store the color inside the alpha strategy.

I'm not sure I like that from a design point of view. In the end, I want to 
offload rendering things like selection masks, background layer patterns and 
some other things to Qt and perhaps optionally OpenGL. So I don't want to 
have special case features for those things in the colour strategy -- it's a 
display thing, not a data thing.

The rendering pipe as I envision would be:

composite all layers on projection layer
convert layer to qimage
paint selection mask of current layer onto qimage (using Arthur)
paint other stuff onto qimage
blit qimage onto canvas
paint current tool lines, meshes, handles etc.


> Inversion of a mask should always be done directly to the device and not as
> a flag. To do that we need to change the default pixelvalue of the
> datamanager and iterate the touched pixels. I have already changed so the
> default pixelvalue is a property of the datamanager. A function to change
> the property is still missing though.

I'd actually really like to be able to have not just a default pixel settable, 
but a default pattern or even a default pixel callback -- for instance for 
creating canvas structure on the fly. See the texture methods in the wet 
color strategy.

> To avoid having to delete a selection in midlife of the parent layer, we
> need to be able to clear the entire datamanger of its tiles. I have already
> added the clear() function to the datamanager.

Cool! That was one of the things on my todo. Now for a version that clears a 
certain rect, instead all of it.

>
> Bart or Adrian. the fillpainter currently abuses the selection when no
> selection exists. If the selection is to be persistent this is no good.
> Also the fill is currently different if an area is selected or not. It
> would be very nice if this could be changed. Is this possible, and easy ?

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050417/9684f1e4/attachment.pgp