Emoji IO was the first challenge, as without proper and integrated IO, there couldn't really be anything useful made of Emojis. This is often the part that nearly everyone has asked me about when showing short sneak-peeks about the IDE, since as to my knowledge, it has never been done before.

When the bot is started up, a webserver is also started (By default on port 80). This webserver is a custom HTTP implementation made with SimpleNet to fetch requests (docs: SimpleWebListener).

The endpoints available (All GET) and their required query parameters are:

This endpoint returns some JS to make a request to /e with the same parameters, plus a random r query parameter. The reason this exists, is to automatically close the page properly. I forget the details but trust me, it works.

The same as the /s endpoint but sends all data to /z.

Not requested directly via the IDE, but by the JS returned by the /s endpoint, used for keypresses.

%1 = Signifies the key being pressed. The ""regex"" format is:

(A[32-126])|(E\d+)

The above block was like half-assed regex that wouldn't actually work but is a lot more readable than what it would be. If the string starts with A, it is an ASCII character, and the following will be a character with the ASCII code of [32-126]. If it begind with E, the remaining string must be a number with the ordinal value of a StaticEmoji. Ordinals are vital to the IDE and will be seen many more times in the wiki, as the URL length of everything matters heavily, as Discord embeds have maximum character limits that are very easy to reach. This value, before being validated, is passed directly to the SimpleKeyboardInputManager#handleKey(String) method.

%2 = A random number, which stops any duplicate requests that sometimes would happen.

Not requested directly via the IDE, but by the JS returned by the /c endpoint, used for web callbacks to allow arbitrary code to listen for a user to click a link.

%1 = A random number, which stops any duplicate requests that sometimes would happen.

Any other query parameters are passed to the internal API, via the WebCallbackHandler#handleCallback(String, Map<String, String>) method. See the next section for listening to IO in your own code for more info on this.

Returns a boolean, if the web mockup has been modified, requiring the browser to reload itself. Only used when the Displayer implementation is set to MockupWebpageDisplayer.

Since the Keyboard is such a prominent part of the IDE, here's a cool section for it. Below is an image of the keyboard for reference.

The keyboard consists of 10 inline fields 2 on each row. This is due to Discord's heavy length limitations of fields, and despite the short emoji names, links for each one still take up a lot of length. Any blank space is provided by the :transparent: emoji, as they would be misaligned if each field did not have exactly 9 emojis in it. When you click a button, your browser will open a tab that sends a request to the bot of the key code (See the /e endpoint above for key naming), and then closes the tab. The IDE then responds properly to the value.

When something like the Control key is pressed, the keyboard is edited to have a background on the key for a few seconds, changing the keyboard's state. During this changed state, it will assume all following keys are meant to be a key combination. This holds true with the logic of the Shift key as well, but assuming all keys should be turned to their "shifted" counterparts (Capital letters, and special symbols for others).

If you feel like implementing something with IO yourself, it's pretty easy unless you're a dumbass.

To listen for a key press, just register and listen to the KeyPressEvent with the IDE's custom event system (If I forget to add the link for it, either make an issue or search for itself you lazy bastard).

Link callbacks are a powerful feature that is used primarily by the help menu of the IDE. Whenever a message is generated with the links, the message ID, channel ID, and requester ID are in the query parameters usually. This being said, those parameters are not required for other purposes. Any query data could be required. Links to raw links can be created by WebCallbackHandler#generateLink(String,Map<String, String>). These links can be listened to by WebCallbackHandler#registerCallback(String,List,Consumer), with more advanced methods which call that method in the same class, e.g. to create one for running commands specifically that requires the channel and member query parameters, and that also verifies them.

Examples of methods like these are in pretty much every command class, such as for the info command here, with more advanced examples below that line. For example, below that line registering the inspect callback requiring the emoji query parameter with the following line of code

callbackHandler.registerCommandCallback("inspect", Collections.singletonList("emoji"), (member, channel, query) -> inspect(member, channel, new ArgumentList(new CommandArg(query.get("emoji")))));

A link that a user can click to run that is made by

callbackHandler.generateMdLink("inspect", "inspect", Map.of("member", member.getId(), "channel", channel.getId(), "emoji", emoji.getName()))