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

List:       openjdk-openjfx-dev
Subject:    Re: [API Review] RT-15314
From:       Daniel Zwolenski <zonski () gmail ! com>
Date:       2013-05-31 0:11:57
Message-ID: CANbPsPx4Fkfn_YcbOZDwcxkgvTxBRxY-SuWCjicMh90RobHuTQ () mail ! gmail ! com
[Download RAW message or body]

+1 on system property only at this stage.
+1 on John's comment about escape key.


On Fri, May 31, 2013 at 4:23 AM, John Hendrikx <hjohn@xs4all.nl> wrote:

> Does "fullScreenWarning=false" imply also that the escape key would be
> free for normal use?  Removing the overlay is definitely good, but for apps
> that always run full-screen they shouldn't react to escape either.
> 
> --John
> 
> 
> On 29/05/2013 23:51, David Hill wrote:
> 
> > 
> > We have a request \
> > <https://javafx-jira.kenai.**com/browse/RT-15314<https://javafx-jira.kenai.com/browse/RT-15314>>
> >  to allow non-sandboxed applications to disable the "ESC to exit full
> > screen" overly (and the associated ESC action to exit Full Screen).
> > 
> > This is needed for "kiosk" style applications where Full Screen should
> > only be under programmatic control.
> > 
> > I have several options to present, but all of them have an underlying
> > change, which is the addition of a system property to disable the overlay
> > behavior:
> > -Djavafx.fullScreenWarning=**false
> > 
> > API Option One: Add to Platform, providing for a system toggle that is
> > static.
> > public static void setFullScreenWarning(boolean warn)
> > public static boolean getFullScreenWarning()
> > 
> > Note: I considered other options, like Application, but felt they were
> > poor fits. I am willing to listen to reason though.
> > 
> > API Option Two: Add to Stage. This would be a per instance change, and
> > not a global toggle:
> > public void setFullScreenWarning(boolean warn)
> > public boolean getFullScreenWarning()
> > 
> > API Option Three: don't change the API at this point, rely only on the
> > system properly to disable the overlay.
> > 
> > Note: option three seems to be a reasonable solution for many of the
> > users of this functionality, because in a "kiosk" style application you can
> > control the launching anyway.
> > 
> > 
> 


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