Research: What are the limits of GUI's in MC
Matts opened this issue ยท 3 comments
Before designing GUI's for 2.0 and 2.1 we need to know what is and is not possible (wanting to do a drag & drop system for #15)
Draggable components seem to be easy, check 8f0aaef for initial tests.
Will see if I can get some custom components working in this setup. Will try and get a custom component working for text
This can be handy for changing the positions of buttons (config options)
Also we could create a drag and drop programming system like this. Will have to research the best way of storing the commands first though
I've been redesigning GUIs in my mod earlier, and I would say that you might wan to implement some kind of framework for your GUIs on top of GuiScreen
capabilities (which will make managing GUI code so much easier).
In my system, I have a simple implementation based on an interface which every GUI element should have. Every element can handle user input (mouse and keyboard), draw itself and has some two additional states (isEnabled()
can handle user input, and isVisible()
). Then every basic implementation also has methods to toggle those states, and also few utility objects to handle bounds and resizing (Area
and Resizer
classes).
Mouse down click and mouse scroll events can prevent the event by returning true
, so this way it's possible to cancel falling through events for foreground overlay element. Besides that, most of the input fields (buttons, text fields, etc.) are using callbacks to handle change in values (which is so easier than manually writing values in user input methods such as mouseClicked
, keyTyped
, etc.).
If you want to take a look, here is the package which contains the framework, and here is some example code. It's not 100% done, I might implement value containers which would allow easier managing and syncing values between fields much easier.