[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Region PickOnBounds default setting
From:       pavel.safrata () oracle ! com (Pavel Safrata)
Date:       2012-06-28 8:00:42
Message-ID: 4FEC0F2A.6060406 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]