Region PickOnBounds default setting

Thu Jul 5 15:17:36 PDT 2012

Pavel, We recently found that bug in PieChart and have set PickOnBounds to false for all Pie slices.

Jasper

On Jun 28, 2012, at 1:00 AM, Pavel Safrata wrote:

> 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
>>>>>>>>> 
> 
> 