Interface Window

  • All Superinterfaces:
    NativeSurface, NativeSurfaceHolder, NativeWindow, ScalableSurface, SurfaceUpdatedListener, WindowClosingProtocol
    All Known Implementing Classes:

    public interface Window
    extends NativeWindow, WindowClosingProtocol, ScalableSurface
    Specifying NEWT's Window functionality:
    • On- and offscreen windows
    • Keyboard and multi-pointer input
    • Native reparenting
    • Toggable fullscreen and decoration mode
    • Transparency
    • ... and more

    One use case is GLWindow, which delegates window operation to an instance of this interface while providing OpenGL functionality.

    All values of this interface are represented in window units, if not stated otherwise.

    Coordinate System

    • Screen space has it's origin in the top-left corner, and may not be at 0/0.
    • Window origin is in it's top-left corner, see NativeWindow.getX() and NativeWindow.getY().
    • Window client-area excludes insets, i.e. window decoration.
    • Window origin is relative to it's parent window if exist, or the screen position (top-level).
    See NativeWindow and Screen.

    Custom Window Icons

    Custom window icons can be defined via system property newt.window.icons, which shall contain a list of PNG icon locations from low- to high-resolution, separated by one whitespace or one comma character. The location must be resolvable via classpath, i.e. shall reference a location within the jar file. Example (our default):

    The property can also be set programmatically, which must happen before any NEWT classes are touched:
       System.setProperty("newt.window.icons", "jogamp/newt/assets/jogamp-16x16.png,jogamp/newt/assets/jogamp-32x32.png");
    To disable even Jogamp's own window icons in favor of system icons, simply set a non-existing location, e.g.:

    Use of Lifecycle Heavy functions

    Some of the methods specified here are lifecycle-heavy. That is, they are able to destroy and/or reattach resources to/from the window. Because of this, the methods are not safe to be called from EDT related threads. For example, it is not safe for a method in an attached KeyListener to call setFullscreen(boolean) on a Window directly. It is safe, however, for that method to spawn a background worker thread which calls the method directly. The documentation for individual methods indicates whether or not they are lifecycle-heavy.