Input elements and devtools

Been a while since I wrote any updates here, apologies, real life got in the way.

But alas, I've reworked some stuff and added support for <input/> elements. I had some issues implementing these elements and confusion conceptually, mentioned below.

Going public

I finally went "public" with this project, meaning I posted it on HangarMC and made the repository public and posted about it to the PaperMC Discord.

So the project's finally open source. Let's see what that brings.

Input elements

If you've used the <input> HTML elements, you know what I wanted to get out of these. But in case you don't, this is an HTML input element:

Basically, it lets you input text that the page can use somehow. The above shown input is styled the same way as it is styled by default in Delphi.

Before making an input element, I had to come up with how the element would take input from the player. The first and easiest solution I came up with was to use Bukkit's Conversation API. But, that has an issue, it takes all chat input as conversation input. Which is perfect, but you can't provide custom suggestions for non-command chat as dynamically as you can for commands.

So I had an idea, use a command like /delphi-input <input> to access take input and also provide suggestions. When a player clicks on the input element, they're placed into a map, with a timeout of a minute or so. When the player inputs that command, it can fetch the element they're inputting to and get appropriate suggestions or anything. With this, the text in the element could change dynamically with each call to the tab completion method.

I ultimately decided against the command solution because using the Conversation API was easier, faster and felt it made more sense, you open chat and type in the input.

If I decide the other method to be better, I might refactor in the future.

After some small changes to the render system, a new event and some other minor additions, the input element was fully supported. In the end, it uses a global listener to listen for clicks on input elements, which then uses a Bukkit Conversation to listen for input from the player.

What's left?

• Handle the active state of the input element differently. While the element is waiting for input it should be considered active.
• While active, it should prevent multiple players from trying to input into the same element at once.
• Support for the prompt attribute that the Bukkit Conversation will use when prompting the player for input.

DevTools

If you've ever worked on frontend design on the web, or just right-clicked and clicked on "Inspect Element", you've used your browser's devtools. Devtools show you an overview of the HTML and effective CSS of elements among many other things. It is an amazing tool for debugging and working with web design. So it makes sense that Delphi should have something similar.

As of writing this post, the devtools only shows the XML layout of a Delphi page and nothing more. But I'm hoping to add the following:

• A "Devtool Stick" that, when used to right click on an element, opens the devtools window.
• An overlay that shows the padding box, border box, outline box and margin box of an element when hovered over with a devtool stick or when the corresponding element's XML is hovered over in the devtools window.
• A css explorer (Or whatever it's called) for selecting an element in the XML tree and then inspecting its effective CSS rules and inline style.
• A document info tab that shows you metadata about a page, along with a few buttons (such as the debug XML dump)
• Inspect element interactivity. This means clicking on elements to get a dropdown to remove it, change the tag name, add/remove attributes or other things, clicking on attribute values to edit them, clicking on the name to rename, or remove it, etc. The CSS for these things is kinda already set up, with hover colors to indicate things can be interacted with, but the logic itself isn't implemented yet.

  This will require a future technology: Drop downs or just context menus that appear when you right click select elements.

I added support for a new type of module, as well: Hidden modules. These will be internal modules at the moment. I basically only added this so I could support the devtools module without it being visible to anyone typing in the command.

Misc. Changes

I moved the logic that handles <java-object> element logic to a System instead of performing the logic inside the element class itself.

The ID system itself was also moved to its own System, which for a couple hours caused me strife because I used a getTarget instead of getNode when listening to mutation events.

Notes

1. Think of XML nodes and elements as components/entities in an ECS. Systems are like the Systems of entity component systems. They handle the logic of the elements, which themselves are just data