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

List:       openjdk-openjfx-dev
Subject:    Re: [API Review] RT-17024: Region pickOnBounds default value
From:       Pavel Safrata <pavel.safrata () oracle ! com>
Date:       2013-02-28 19:48:43
Message-ID: 512FB49B.5050100 () oracle ! com
[Download RAW message or body]

Hi Richard,
I'm not sure that the behavior is much less disastrous. In the use-case 
with a rotated button in a  pane, instead of being unable to click the 
button, you'll be able to click half of it :-) There is another option 
to have a flag "pickOnBoundsMeansToPickOnSizeAfterNoChildWasPicked". So 
we would do the width/height plane picking only if no child was picked; 
the children would have priority even behind the plane. This would make 
the transparent layout containers behave well, at the expense of filled 
panes with children obscured by the fill, which sounds like a good deal 
to me. I must add this whole construction starts to look like a pretty 
complicated workaround :-)

Pavel


On 28.2.2013 18:50, Richard Bair wrote:
> Hi Pavel,
> 
> Alright, very good. So I think basically adding "pickOnSize" essentially would \
> perpetuate the current design's pros & cons in the 3D space (a transparent pane \
> still behaves unexpectedly, but not so disastrously as pickOnBounds presently \
> does). 
> Another way to look at it is that "pickOnBoundsMeansToPickOnSize" would be true by \
> default, such that if pickOnBounds is false then the meaning of \
> pickOnBoundsMeansToPickOnSize doesn't matter -- that is, the flag is only used to \
> modify what is meant by "pickOnBounds" rather than being a different flag entirely. \
> In this way pickOnBounds stays true, but pickOnBoundsMeansToPickOnSize would also \
> be true. The only incompatible behavior is for those cases where a child was \
> located outside the width/height of the pane. 
> I'm not advocating the solution but just exploring it.
> 
> Richard
> 
> On Feb 28, 2013, at 9:03 AM, Pavel Safrata <pavel.safrata@oracle.com> wrote:
> 
> > Hi Richard,
> > 
> > On 28.2.2013 17:16, Richard Bair wrote:
> > > Thanks for the excellent summary.
> > > 
> > > > *Arguments against switching region pickOnBounds to false by default*:
> > > > 
> > > > First of all, it is a backward incompatible change!
> > > Right, this would be a binary & source compatible change, but would be a \
> > > behavioral change and a change to the specification. 
> > > > This is a strong reason. It will cause some behavioral problems to existing \
> > > > controls and applications. Some of the existing control skins rely on the \
> > > > current behavior and may misbehave after the change, it looks like nobody is \
> > > > able to fully assess the potential impact. There are other things like small \
> > > > icons implemented as regions (the arrow in combo box) which would now be \
> > > > picked only exactly on the shape etc. Another serious issue is that some \
> > > > users use empty panes for the purpose of blocking mouse events, for example \
> > > > during data loading or showing in-scene dialogs. All those things will have \
> > > > to be fixed in controls and user apps. 
> > > > Then there is performance. Obviously, checking all the possibly complex \
> > > > visuals of a region takes more time than just checking the rectangular \
> > > > bounds. So changing the default value will have negative performance impact. 
> > > > Finally, if the current behavior doesn't fit, there is fairly simple \
> > > > workaround - just call setPickOnBounds(false). You need to be aware of this, \
> > > > and for some use-cases you'll have to do this often, but still it lowers the \
> > > > push for the change considerably.
> > > It seems to me that the current status quo isn't going to work -- having a mode \
> > > which is effectively useless for 3D seems just wrong (especially since it was \
> > > arguably not right for 2D either). So we need to make a change. So some ideas: 
> > > 	- Change Region.pickOnBounds to false by default and fix up all the controls.
> > > 		- Any users who have need of picking on the bounds (such as combo box arrows, \
> > >                 scroll bar arrows) have to set the flag
> > > 	- Change Region.pickOnBounds, but leave Control.pickOnBounds as true
> > > 		- Less revolutionary change, but makes it so that layout containers work \
> > >                 right in 3D with the least amount of breakage
> > > 	- Add a new "pickOnSize" property to region, default to true. Switch \
> > >                 pickOnBounds to false.
> > > 		- pickOnSize would pick on the 0, 0, width, height, but only as a single \
> > >                 plane
> > > 		- This effectively leaves the behavior the same as it is currently, but also \
> > > works (?) in 3D 
> > > This last option just occurred to me a couple minutes ago, not sure if it \
> > > works?
> > This is a very interesting idea.  The biggest problem with it is that people \
> > already put "setPickOnBounds(false)" on many places where they needed the precise \
> > picking. After this change, this call would become useless, it would start \
> > picking the entire rectangular area again. Users would have to replace the call \
> > by "setPickOnSize(false)". 
> > Here is a quick evaluation of its other characteristics:
> > 
> > - for controls (the little icons etc.) the behavior should remain the same
> > - for usual panes, the behavior will remain the same
> > - layout containers still eating events
> > - user apps using glass panes remain working as before
> > - the problem with panes with far-away children will be fixed
> > - after the change it won't pick the space between the pane and the child
> > - 3D will work (more or less)
> > - the rotated children will be picked just fine
> > - the children obscured by region's fills will be picked correctly, however
> > - it will do the same thing even for regions with no fills
> > 
> > The last line is a problem. If you put some 3D stuff in a layout container, it \
> > will pick the children where they are "above" the XY plane, and the container \
> > where they are "below" the plane. 
> > Regards,
> > Pavel
> > 
> > > Richard


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