Lemur: Window Extension

Contribution Depot
#1

Lemur-Window

An implementation of windows using the Lemur framework.

  • Draggable, restricting movement to within the constraints of the camera dimensions.
  • Minimize, Maximize and Close TitleBar buttons.
  • Close button can be overridden with the boolean windowClosing() event.
  • Built-In Dialog functions.
  • Automatic z-indexing.

JCenter Dependency

Download 

repositories {
    jcenter()
}

dependencies {
    implementation 'com.jayfella:lemur-window:1.0.1'
}

Example Useage

The test class outlines all of these abilities.

Available on jMonkeyStore

8 Likes
#2

Thanks to your great work with Lemur, there seems to be a working alternative to AWT/Swing.

Just an idea, maybe Lemur could be used for the SettingsDialog instead of Swing? And then avoid the issues related to AWT/GLFW on MacOS.

1 Like
#3

There are a couple issues with that… to use Lemur you have to first bootstrap a whole jME window, and hope the settings that you’re going to be adjusting in the settings window are OK and don’t cause a crash. If they are a problem, you’re permanently locked out until you hunt down and manually override the saved settings. You also have hard choices to make between launching a whole new JVM or dealing with having multiple SimpleApplication instances (settings + the main application) in the same JVM (which don’t tend to play nicely).

Lemur is a fantastic toolkit once you have a jME instance up and running, but it’s not really a substitute for desktop-native UI toolkits.

3 Likes
#4

I tend to either go for a custom external settings panel like the javafx one i made, or let the user change it in-game and restart. Neither are better or worse.

2 Likes
#5

Hi @jayfella

What do you think about turning SimpleWindowManager into an AppState?

On initialize it should create and attach WindowUpdaterState and on clean up it should detach it.

On enable it attaches windows to GUI node and also enables the WindowUpdaterState on disable it detaches windows from GUI node and disables WindowUpdaterState.

Also this way it will be freely available for other app states to add/remove their windows.

Any thought?

#6

Hm.

I think my original thinking was that it is a WindowManager that has an update loop, and is not necessarily an Application State itself, though I can see how those thought processes can kind of cross over into one another. I also didn’t want people using the StateManager to get the WindowManager. It felt more elegant calling DevKit.getInstance().getWindowManager(). But if the devkit didnt exist, an appstate would have made far more sense.

I guess with programming ethics aside it would make things a lot easier. I mean if it makes it more usable then there’s no harm.

1 Like
#7

Yeah, DevKit.getInstance().getWindowManager() can yet be there as well.

A good example is PopupState in Lemur, it can be accessed either from state manager or GuiGlobals.getInstance().getPopupState().

#8

Oops! :see_no_evil:

This way you won’t even need this private class anymore:

you can safely remove it and move the functionality into window manager state. :slightly_smiling_face:

#9

Yeah. I don’t mind it being an appstate. I’ll update it so it becomes an AppState.

1 Like
#10

It’s done @Ali_RS - I’ll push an update shortly to jcenter.

1 Like
#11

Done. Its in jcenter. v1.0.1

1 Like
#12

Thanks so much.

1 Like