Region PickOnBounds default setting

Thu Jun 21 08:37:17 PDT 2012

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