It would be more beneficial for you to know how to hard code GUIs before reading this.
I enjoy creating GUIs. It's challenging, because there's quite a bit to consider in order to get them just right! Friendly UX (User Experience) Either your users are dumb, or the way you've constructed your GUI is misleading and/or has contradictory decisions (e.g., 'power-mine' and 'bank' check boxes). Secure As mentioned above with the contradictory decisions: never allow them. Be strict and firm with the freedom's you're giving to your users, so they don't end up making mistakes. But also make sure the user cannot NOT make decisions, for instance, prevent the bot from working until your users have told your bot what it needs to know in order to work in the first place. Externalise GUIs included in the main script code will make the code look ugly and bulky, because GUI code is always ugly and bulky. Having your GUI code saved in a separate class (aka. code saved in a separate file) and loaded in will make your code look a hell of a lot better! OOP Following on from the previous point; there's various ways to have information sent from your GUI to your script, but the best (in my opinion) is to use OOP. Example:
I have not focused on UI (User Interface), because this is just proof-of-concept.
The box to the top is a list inside of a scroll pane (when list becomes bigger than box, scroll pane is used to allow scrolling).
The text field underneath is where you type monster names and you can separate them with a comma.
Notice the space between the 'add remove' buttons and the check box below? That's to hint that those buttons relate to the list above and not the stuff below.
Notice the '25' up-down box (aka. spinner) to the bottom-right is disabled; that's because 'Run away when health falls below' is disabled. This is part of UX -- prevent options from being interacted if they're ultimately pointless to the user.
Most importantly: the 'Submit' (aka. "start", "go", etc.) button is DISABLED until the list has names inside of it, otherwise what the hell is my bot going to do? ...
The names I had entered were 'trimmed' to avoid spaces before the name (e.g., " GUARD"), and I have capitalised all the names so that case sensitivity is not a concern for the user, and the list cannot be populated with crazy-case names (e.g., "GuaRD"). It looks cleaner.
I have enabled that spinner for the check box, because the check box is selected.
The submit button is now enabled, because the bot actually has something to work with.
However there are more UX features that are working behind the scene!
You can select multiple items in that list and hit [backspace] or [delete] and they will be removed. When doing this, the next list item to be selected will be the one before the one you deleted, to make it easier to delete multiple items just by using your keyboard.
When entering names into the text field, when you hit [enter] the names are added to the list.
When adding names (either by [enter] or 'add'), the text field is cleared.
You cannot enter the same name twice into the list; this removes unnecessary duplicates.
Here's the code: SomeScript.java (Script) Look at the loop() method: the bot will not do anything until the user is finished with the GUI.
Display.java (GUI)
Instruction.java (Object) This object contains the cut-and-dry of the GUI based on the user's choices. Having the information from the GUI stored this way not only makes it easier to handle in our script, but also means we can use APIs such as JSonSimple to extend this object and make it possible to save the user's decisions locally, and then have the script load them at the user's behest.
SubmitListener.java (Interface) In order for our Script to receive the user's instructions from the GUI we need some kind of method that allows for that communication. So what we do is we have this SubmitListener as a variable in the GUI, then we add some public getters/setters to allow the Script to set the SubmitListener inside of the GUI, then the 'submit' button in the GUI will then callback the script using this variable IF this variable has been set.
With all this the Script can create the GUI, add the necessary interface to allow the GUI to callback to the script when the user's made their decision, then to dispose of the GUI when the script has stopped. To me, this makes the GUI feels more natural.
This is just a rough draft; may improve thread later.