Region PickOnBounds default setting

Mon Jul 9 06:40:40 PDT 2012

Ok but still it could have worked as expected automatically if the 
default value was correct. Issues like this will probably appear everywhere.
Thanks,
Pavel

On 6.7.2012 0:17, Jasper Potts wrote:
> 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
>>>>>>>>>>
>>