Region PickOnBounds default setting

Thu Jun 28 01:00:42 PDT 2012

I'm sorry for the delay. I commented on the issue and attached the 
EvilPane there. I also described another problem I just noticed:

Another example is picking slices in a pie chart. Right now it by 
default picks completely wrong slices because each slice is a region and 
is picked on bounds that cover large portions of neighboring slices. You 
have to do a "data.getNode().setPickOnBounds(false);" exercise for each 
slice to make it behave reasonably.

Thanks,
Pavel

On 21.6.2012 17:37, Richard Bair wrote:
> Ah I see the problem. Pavel can we make sure there is some text in the issue describing the problem (ie bounds != region width/height, and thus pick on bounds is undeniably wrong in that case).
>
> Dan -- the bounds always must include the bounds of all stuff, without putting a clip on every region you have to be prepared for layout bounds != bounds in parent / bounds in local.
>
> Note that putting a clip on regions by default would be a huge mistake. You wouldn't be able to do a number of common effects where you are translating children outside the bounds of the container. It is the difference between basic form like apps and more graphical ones.
>
> On Jun 21, 2012, at 4:48 AM, Daniel Zwolenski <zonski at googlemail.com> wrote:
>
>> I just ran the code (thanks Pavel!) and I agree. While I see the problem
>> with the picking, a bigger problem in my mind is that the max bounds are
>> not being honoured. The picking to me is just a side effect of some odd
>> layout sizing behaviour.
>>
>> My expectation with this code is it should either honour the max bounds and
>> clip the child nodes (my preference) or, if it's really not going to honour
>> the max bounds, then it should stretch the region to the bounds that it is
>> actually covering. The hybrid thing it is doing is just weird in my
>> opinion.
>>
>>
>> On Thu, Jun 21, 2012 at 9:39 PM, John Hendrikx <hjohn at xs4all.nl> wrote:
>>
>>> Not sure if interested, but coming from someone who has never seen this
>>> before... I must say it certainly looks counter-intuitive.  Why does the
>>> evilPane have such big bounds?  It is restricted in layout to a max size of
>>> (50,50)... and thus I would expect the blue child to be clipped and the
>>> pane Bounds to be reduced to no more than (50,50).
>>>
>>> But I guess that is because of the tree style rendering that JavaFX does,
>>> where nodes can exceed their layout bounds when effects/translations are
>>> applied... as I said, it certainly looks counter-intuitive, in more ways
>>> than one coming from someone who is used to Container/Groups strictly sized
>>> to fit their children, and clipping the children that will not fit.
>>>
>>> --John
>>>
>>>
>>> On 21/06/2012 10:44, Pavel Safrata wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> On 20.6.2012 21:55, Daniel Zwolenski wrote:
>>>>
>>>>> Assuming I understand the problem then I've hit this sort of layout
>>>>>>> problem and my instinct was to look
>>>>>>> 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.
>>>>>>>
>>>>>> The pane from the description is small and is in a top-left corner. It
>>>>>> can be styled, and you can see it there. There is no code that would make
>>>>>> the pane big to cover the whole scene, there is no way to make it visible
>>>>>> in the whole area, because it's just not there.
>>>>>>
>>>>> I am perhaps missing something, but "Pane's bounds will then cover whole
>>>>> sceen" implies to me the pane is stretched, so if I styled it I would see
>>>>> it stretched. The description of #2 is a bit vague to me though. I guess a
>>>>> code example would clear this up but it probably doesn't matter that I dont
>>>>> understand.
>>>>>
>>>> The pane is not necessarily stretched to embrace all its children. I've
>>>> attached a code example that shows the problem.
>>>>
>>>>
>>>>> I'm guessing, for example, if this fix went in it would break all my
>>>>>>> 'glasspanes'?
>>>>>>>
>>>>>> I cannot say unless I know how your glasspanes are implemented...
>>>>>>
>>>>> I use glass panes to block the screen in two cases: when loading and
>>>>> behind a light box (ie embedded dialog).
>>>>>
>>>>> In both cases my glass pane is just a pane (eg BorderPane) added to the
>>>>> top of a StackPane with the rest of the app added to a lower layer of the
>>>>> stack. In the loading case it has no children, in the dialog case it's
>>>>> child is the dialog.
>>>>>
>>>>> The loading one is transparent but has an in-progress cursor when you
>>>>> mouse over. In the dialog case, the pane is a translucent grey, though you
>>>>> could style it differently and transparent would be a valid style (making
>>>>> the fill color define if it is clickable would not be nice for me and is a
>>>>> little scary).
>>>>>
>>>>> In both cases the point of it is that it blocks mouse input to the
>>>>> scene. I'd prefer this didn't break in a future release (sorry!). If auto
>>>>> updating (my nemesis) wasn't on then I'd be ok for it to change and then I
>>>>> fix my apps before moving to a higher version but it magically working one
>>>>> day and not the next would be pretty nasty for me.
>>>>>
>>>> It would break your glass panes only if they have no fill (which I agree
>>>> is bad enough). Pane with transparent fill would still block mouse events.
>>>> I'm not sure why this is scary, this approach is used everywhere in FX
>>>> except of Region.
>>>>
>>>>
>>>>> 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.
>>>>>>>
>>>>>> I'm really sad that we've let this go that far, it could have been
>>>>>> fixed before our first release. If the decision comes that it's too late by
>>>>>> now, the way how to deal with it will be clear (setPickOnBounds(false)),
>>>>>> but I doubt it is (and could be) intuitive.
>>>>>>
>>>>> For me the current default behavior seems intuitive: the pane is
>>>>> clickable for whatever area it takes up. I get the feeling I might be
>>>>> missing something here though as it is obviously a concern for some people.
>>>>> Sorry if I have misunderstood.
>>>>>
>>>> I think the attached example shows pane that is clickable in area that it
>>>> doesn't take up.
>>>>
>>>>
>>>>> For me the only problem with the current approach is that in some cases
>>>>> I'd like a pane used purely for layout (anchor pane as top layer of a
>>>>> StackPane is a prime candidate) to not catch mouse clicks but the children
>>>>> on it still should. Calling setPickOnBounds(false) and setShape(null) to do
>>>>> this is not intuitive to me but I'm glad I now know its possible as I've
>>>>> struggled with this before (and possibly raised a bug, will have to check).
>>>>>
>>>> This is exactly the most common problem that would be solved. You see
>>>> you're glad that you now know how to solve it, but other users will keep
>>>> bumping into this issue..
>>>>
>>>> Thanks,
>>>> Pavel
>>>>
>>>>
>>>>> Thanks,
>>>>>> Pavel
>>>>>>
>>>>>>
>>>>>>> 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<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<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
>>>>>>>>