FoxCore Window/CUI System Discussion


FoxCore Window System Discussion

This is a discussion post for suggestions and feature requests of a yet to be fully implemented addition to the FoxCore Plugin.

What is this system?

It is an advanced windowing/CUI system for Minecraft.
It was initially designed for FoxEdit, but has since been planned out in an abstract way in which any plugin/mod should be able to link to.

This is a short (and pretty terrible) video on a few of the current features:

Planned Features

  • FoxLang Bindings
  • Theme/Skin System
  • Dynamic Plugin System
  • Easy Window Builder (XML? JSON? Other?)
  • Server & Client Support
  • Rendering System
  • In world 3D rendering (allows regions/areas to be highlighted or have walk up windows + much more)

Planned Window Components

  • Labels
  • Buttons
  • Text Fields
    • Passwords
  • Number Fields
  • Sliders
    • Continuous
    • Discrete
  • Checkboxes
  • Radio Buttons
  • Panels
  • Progress Bars
  • Drop down menus
  • Color Picker
  • Groups (like with the border around them)
  • Tree
  • List
    • Select list
  • Scroll pane
  • Canvas
    • 2D
    • 3D
  • Image Pane
  • File Selector
  • Text Areas

This is a very crude example of the current setup to create a window with some text and a button that does stuffs.

 this.window = new Window("World Start!")
        this.labelComponent = new LabelComponent("Player Position: ")
        final ButtonComponent buttonComponent = new ButtonComponent("Verify!")
                .setClickHandler(integer -> {
                    try {
                        if (InetAddress.getByAddress(new byte[]{8, 8, 8, 8}).isReachable(250)) {
                            final Window notifWindow = new Window("Verified!")
                    } catch (IOException e) {

If you have any ideas or suggestions, please let me know.

I am curious to know if this is something that other people would actually want, so please let me know.

Snowie (d4rk)


This looks awesome
I’d wish something like this was in vanilla Minecraft so mod devs wouldn’t have to rely on chat/book/inventory menus…

I’d hope components will mirror the awt or swing feature set as most Java devs will know those. If the window builder works like it does on Android I’m all for it :smiley: Generally I would like if it would be similar to Android, ofc with windows instead of activities

Would definitely at least play around with it and love to see what people can do with that


Yeah, my current debate is if I should make it more similar to Android, or more similar to Swing/AWT.

I think for now I’m going to try to make it a bit more abstract, so I can have have UI builders that can choose what to read to render.

If I make it Swing it AWT like, I’m not going to be reimplementing the whole library myself, however it will be tree style and have many of the same features.

For now though, a lot of the more hidden or advanced features of items won’t be implemented until asked, or a PR is made.

Are there any other components or things you can think of that you’d like to see. (Or any in that list that would be really high priority?)


@DosMike I added some example code to the main post, it you want to take a look.


You don’t have to fully reimplement it. the way it is looks ok, tho I’d like to see setPosition(x,y) and setDimensions(width,height)

What a lot of people seem to not know is, that you can build activities in android without layout files but in java. it’s not as convenient and you’d have to play around with the display density to properly conver units back to pixels, but it’s possible.

If the “java way” is properly implemented it should be easier to implement a xml parser or alike.

As for the list of components: I can’t think of anything else.
Maybe add someway to anchor elements/windows in the middle.


Looks very nice!

If you’re interested in some other APIs that add GUI components to minecraft, see these projects:



So quick question…

Currently in order for the windows to get server data and vice versa, I am using Forge network channels. This is all fine and good, assuming that the servers will only ever be running Forge/SpongeForge.

Should I also add in the option of using custom connection, which means that this would technically be able to work on any server/client configuration? The downside of this is that afaik, it means the server owner will have to be able to open another port, or I will have to act as a proxy, and the client will need to have a firewall that allows said port through.

Sorry there hasn’t been much news on this, I got distracted helping my grandparents move :confused:


Network channels are not a forge-specific thing. They are part of the minecraft protocol. See:

Sponge has an API for them:


Hm, didn’t realize. Does Forge and Sponge just have direct wrapper around netty?

Also don’t they have a pretty small limit on custom payload size (like a short or something). Maybe I was missunderstanding what I had read, or it was very outdated, but I’ll take a look at those links later.


Basically, yes. Forge wraps Netty, SpongeForge then uses the low-level forge implementation to implement sponge’s API. SpongeVanilla implements directly on top of Netty.

I think that is still the case. I believe forge is able to handle larger packets and breaks them into smaller ones (though I don’t know whether that’ll be the case in sponge). You can always try gzipping the content if you reach the limits.