setLocation(x, y) //left, top


#1

I found how to set the windows location but it is not intuitive.
Display.setLocation(left, top);
Is it possible to add a setting for setLocation() or a procedure in some level of the application? I don’t think you can return the static ‘Display’ but, getDisplay() would allow you to press ‘.’ and get Display.setLocation(left, top);


#2

Not sure if I understand. Press ‘.’ for autocomplete in the IDE?
Display seems to be a class of X11? That won’t work on windows (/mac?).

We use GLFW to set the window position:

    LwjglWindow win = (LwjglWindow) getContext();
    GLFW.glfwSetWindowPos(win.getWindowHandle(), x, y);

getContext() is a member of jme’s Application Interface.

But yeah I guess it would be more elegant to have it in AppSetting :slight_smile:

(we use it for alignment with other windows)


#3

That I guess is LWJGL 3. The OP is clearly using LWJGL 2. There is the Display class.


#4

I see. Yes it’s LWJGL 3.


#5

I was looking into

LwjglWindow win = (LwjglWindow) getContext();
GLFW.glfwSetWindowPos(win.getWindowHandle(), x, y);

You have to have the Lwjgl library to do that but, It’s not in the standard install. More effort for something so basic. At least, the IDE couldn’t find it when I tried a Fix Imports.
Yes, I’m using JME 3.2.
Yes, more elegant is the word. Well, two words. It makes is more accessible.


#6

The thing is that JME comes with both LWJGL 2 & 3. 2 being used by default. To switch, you need to manually do it. This is not really related to your question, just to clarify. If you are going to use the LWJGL stuff directly, then you need to care about this a little. As 2 & 3 APIs are very different.

I guess the reason why version 2 is still the default is that there are few issues with MacOS in version 3. And compatibility issues between Swing && version 3 && Linux.


#7

Note that jme3-lwjgl3 also has a serious issue with non-US keyboards:
https://github.com/jMonkeyEngine/jmonkeyengine/issues/942

Regarding the OP’s request: Adding a getDisplay() method to some jme3-core class probably isn’t a good idea, since it would only work with LWJGL 2.x .


#8

I guess it would be just in the core interface (I can’t pinpoint which). The real implementation of course would be in the… well, implementation classes such as the LWJGL 2 and LWJGL 3. A bit poorly expressed but I’ll guess it is understandable what I’m trying to say :slight_smile: