Posted by Sven Gothel on May 18, 2010; 2:25am
URL: https://forum.jogamp.org/Feedback-on-Newt-bindings-by-lhkbob-tp823824p825191.html

On Tuesday, May 18, 2010 01:48:01 lhkbob [via jogamp] wrote:
>
> With regards to using the screen width/height, in Newt's Screen class all I
> see is a way to get the width and height.  
Yes .. since we cannot help you with changing the screen dimension,
ie we have no kernel mode setting feature integrated which would exceed NEWTs intention here  :)

> The setters are protected.  If I
> set the Newt Window's size, it's ignored when I tell it to go to fullscreen
> mode.  
Of course .. fullscreen is fullscreen.
But you can create an undecoreated window, and set it's size,
if this is really your intention.

> I think this is something that could easily be added to the screen or
> display classes (I'm not sure which would actually be responsible).
Please make your point, ie describe your use case.

>
> For my 2/3 points, I would be willing to look into it, but it would be
> helpful if you could point me towards some good literature.
Then I would have the solution myself .. I usually just read Apple's APIs
on their website ..
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/cl/NSWindow
http://developer.apple.com/macosx/multithreadedprogramming.html

The last ref may hold something promising .. but I haven't tested it yet.

>
> With #4:
> The interface NativeWindow has lockSurface(), unlockSurface(),
> surfaceSwap(), getWindowHandle(), and getSurfaceHandle().  All of these seem
> more useful for the actual implementations but not something we want most
> users to see when they just want to make a visible window.
I don't know who you think 'we' is here .. but the developer of the
NativeWindow interface intended it to be very low level and actually is the inter-package
and inter-project vehicle to allow abstraction of a native window/surface.
JOGL for example has to call lock/unlock on a NativeWindow implementation
to access the surface handle, but another package/project, eg NEWT provides the implementation.
So I am afraid we just cannot hide it in NEWT.
The only way would be to obscure it a bit, ie not allowing Window to impl NativeWindow
and create yet another layer of abstraction .. but since this wouldn't help at all .. it's useless.

>
> Within Display, there's getFQName(), pumpMessages(), and when creating a
> Display it's not obvious what's the purpose for having different named
> displays (or if you can choose your own names).
This is a matter of API documentation.
I am sure I added something into the git commit log .. maybe I missed to add something
to the method names .. point taken.
However .. as you can read in the source, FQN is the combination of type + user-name,
so the reason was to have a unique display name across types (unique key).
We have test cases where we mix types within one JVM, ie X11 and AWT.

~Sven