[API Review] RT-17024: Region pickOnBounds default value

[Richard Bair]

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