Region PickOnBounds default setting

[Daniel Zwolenski]

I've always wondered what the behavior when pickOnBounds is false ie. what does it then pick on if not the bounds? Its not intuitive to me from the method name what should happen. 

Assuming I understand the problem then I've hit this sort of layout problem and my instinct was to look for setMouseTransparent(true) on the region as that's basically what I wanted. Problem was it set all its children transparent too. Perhaps another way out of this problem would be some form of non-inherited mouse transparency attribute. Might be more efficient too. 

I'm not sure I agree with the bug description when it says that "both visually and in source code there is nothing in between the pane and the child". In code there is a pane. Visually there would be a pane if you set styles on it. Wouldn't you be just as confused if you were trying to add a pane and it bizarrely wasn't getting mouse events?

I'm guessing, for example, if this fix went in it would break all my 'glasspanes'?

As such, I don't think it needs to be a default attribute now that it's in place the other way round but I do think it needs to be clear and intuitive how to deal with it. 


On 20/06/2012, at 5:41 AM, Richard Bair <richard.bair at oracle.com> wrote:

> Hi folks,
> 
> We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024.  A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258:
> 
>> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: 
>> 
>> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). 
>> 
>> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. 
>> 
>> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. 
> 
> 
> This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true.
> 
> I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think?
> 
> Richard