RFR: 8087980: Add property to disable Monocle cursor

Sat Nov 16 13:52:16 UTC 2019

First time poster so forgive my inexperience...not really anything against
the specific changes just seeking insight...

(1) Notice some of these packages are still in com/sun/glass namespace.  Is
this still valid or at some point should this transition to a more open jfx
equivalent or has that part still not fully been considered yet?

(2) General practices...When should a property be a system environment (1)
in system specific way - Windows environment variable, UNIX shell based
property user or global, (2) app specific properties - internal as a
resource or META-INF type or external to a given jar, (3) application
specific in a give jfx component or class specific properties, or some css
type properties, etc.), (4) command line type parameter passed in, etc?
And that said which type would the properties discussed here for in?

I ask because curious when and where these are needing to be setup as well
(I.e when installing the app set the system environment variable once,
delivered with a property set, run with defaults and later customized in
case by case basis, etc.)

Eric Bresie
ebresie at gmail.com

On Sat, Nov 16, 2019 at 12:14 AM Dell Green <github.com+
12861109+dellgreen at openjdk.org> wrote:

> On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger <github.com+
> 1413266+jgneff at openjdk.org> wrote:
>
> > On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green <github.com+
> 12861109+dellgreen at openjdk.org> wrote:
> >
> >> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger <github.com+
> 1413266+jgneff at openjdk.org> wrote:
> >>
> >>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <
> 12861109+dellgreen at users.noreply.github.com> wrote:
> >>>
> >>>> Often on embedded systems a cursor is not a valid input modality. On
> some of these systems, when the javafx toolkit initialises the native
> hardware cursor, it produces artefacts which can be seen on screen (in the
> framebuffer for example). This change adds a system property
> "monocle.cursor.enabled" that can disable the creation of a native cursor
> in each of the Monocle NativePlatform implementations in favour of a
> NullCursor which is a no-op implementation of the NativeCursor abstract
> class that all native cursors have to implement.
> >>>>
> >>>> NullCursor class already existed and was being returned for some
> implementations like AndroidPlatform and HeadlessPlatform. This change
> builds upon that and conditionally returns NullCursor for all platforms.
> >>>>
> >>>> A system property "monocle.debugcursor" has also been added to turn
> on logging of which NativeCursor has been selected when the toolkit
> initialises.
> >>>>
> >>>> ----------------
> >>>>
> >>>> Commits:
> >>>>  - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor
> >>>>
> >>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files
> >>>>  Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00
> >>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8087980
> >>>>   Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod
> >>>>   Patch: https://git.openjdk.java.net/jfx/pull/5.diff
> >>>>   Fetch: git fetch https://git.openjdk.java.net/jfx
> pull/5/head:pull/5
> >>>
> >>>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java
> line 50:
> >>>
> >>>> 49:         AccessController.doPrivileged((PrivilegedAction<Boolean>)
> () -> {
> >>>> 50:             final String str =
> >>>> 51:                 System.getProperty("monocle.debugcursor", "");
> >>>
> >>> Just a nit, but why `monocle.debugcursor` rather than
> `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`?
> Below is the full list, for comparison, including the two added by this
> pull request.
> >>>
> >>> monocle.cursor.enabled
> >>> monocle.debugcursor
> >>> monocle.epd.bitsPerPixel
> >>> monocle.epd.enableInversion
> >>> monocle.epd.forceMonochrome
> >>> monocle.epd.noWait
> >>> monocle.epd.rotate
> >>> monocle.epd.useDitheringY1
> >>> monocle.epd.useDitheringY4
> >>> monocle.epd.waveformMode
> >>> monocle.epd.y8inverted
> >>> monocle.input.<product>.flipXY
> >>> monocle.input.<product>.maxX
> >>> monocle.input.<product>.maxY
> >>> monocle.input.<product>.minX
> >>> monocle.input.<product>.minY
> >>> monocle.input.<product>.touchFilters
> >>> monocle.input.touchFilters
> >>> monocle.input.touchRadius
> >>> monocle.input.traceEvents
> >>> monocle.input.traceEvents.verbose
> >>> monocle.maliSignedStruct
> >>> monocle.platform
> >>> monocle.platform.traceConfig
> >>> monocle.screen.fb
> >>> monocle.stackSize
> >>>
> >>> I'm nervous about our hidden API of system properties, and I'm as
> guilty as anyone with the nine properties I added for Monocle EPD. I think
> it might be okay as long as the code gets the property values only during
> class initialization. That should restrict their use to startup scripts and
> keep them out of application code trying to modify them *on-the-fly* at run
> time.
> >>
> >> if i recall i originally started with the format you recommend as it
> made more sense, and when looking for other debug logging across the javafx
> stack I picked up on somewhat of a loose existing convention so changed to
> match it. I guess it can be whatever everyone agrees upon. :)
> >
> > On second thought, let's remove `monocle.debugcursor` and use a
> [PlatformLogger](
> https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java).
> The JavaFX loggers are available from [Logging](
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java).
> In retrospect, that's how I managed to avoid any new *debug* properties for
> Monocle EPD even though it's packed with debugging and trace messages. For
> examples, see the variable `logger` in [EPDFrameBuffer](
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java),
> where `logger.fine` is called for messages printed once per run, while
> `logger.finer` is called for messages printed once per rendered frame.
>
> OK, that looks a better way to go. I'll sort out out an additional pull
> request when back in work Monday. Off the top of your head can you remember
> the syntax to change the logger level from command line when starting the
> JVM?
>
> PR: https://git.openjdk.java.net/jfx/pull/5
>
-- 
Eric Bresie
ebresie at gmail.com