Working Out The WYSIWYG Interface

Twinspire is getting its own software, as discussed in our previous post on UI design. The purpose of this software is to help build and generate functions that are reminiscent of the kind of functions you would naturally write for designing interfaces, except for my own purposes, I am looking at multiple possibilities all of which cannot possibly be put into the software.

These are my thoughts so far:

• Make everything something that must be designed. That is using a complete WYSIWYG interface and make it as user-friendly as possible. One of the main advantages of this is the ability to organise code visually and obtain data as if you were already running the code.
• Have a simple command-like interface in which you type as if you were programming, but generate a visual interface representing it. This is similar to above, but is a mixture of programming and WYSIWYG.
• Design or create a programming-like language with a limited set of features that is just for generating code. The disadvantage of this is we lose the benefits of obtaining data visually.

Here is an example of something I have done that would go with the first point:

As an example, this Field Designer is meant for creating fields for structures to be used for data building. It gives all the options you expect from designing a field and this is made like this to serve the benefit of understanding what your fields are doing visually.

Now, here is an example of a command-like interface:

There doesn't appear to be much going on here, but let me explain.

At the bottom, there is text field in which you would start typing something and it would parse this into a visual representation of the code you are intending on typing. This is getting closer to a programming interface than a WYSIWYG interface, but what we could do here is get the best of both worlds.

The space above the text field is designed to be the interface we see from what we type. We could include the ability to create structures, fields, enums and constants from this interface in addition to the interfaces we supplied previously, so you have both options available to you. However, this is just additional work and probably a bit much for our purposes.

One of the main reasons for this interface would be to build procedures, but one of the stumbling blocks here is working out how to visually represent values.

Values can be of any type. Like our fields representing a member variable of a structure with a given type, we would need to cover all bases. That includes Maps (or Dictionaries), Arrays, Structures themselves, Dates, and other basic and complicated types. Hell, how do we represent a pointer? Do we give the address? Obviously that wouldn't show without the running the code, so what do we place instead? Reference to the value it holds or a placeholder? Pointers can make our infrastructure confusing, but it's necessary to cover the ODIN target.

The final option is to go down the route of building a simple programming language as mentioned in the last point, and while this may be the fastest way to get a result, it seems too cheap and fiddly a solution to build. Not to mention the enormous complexity and unnecessary boilerplate.

At some point in the future, what we build here is a temporary solution to a bigger problem: managing and maintaining codebases for Twinspire projects targeting multiple languages, using Raylib as the underlying framework for rendering (or Kha in Haxe).

Just so you know, the Raylib linking has been completed and has been where most of the time has gone these past few weeks. Unfortunately, unlike if you were generating a language binding, this work had to be done manually due to covering all edge cases for the two languages we are targeting with Raylib: ODIN & C#.

No matter which way this goes, Twinspire Studio, as it will be called, is going to take up quite a bit of time to make. However, in the long-term, the expectation is that this will serve to assist in building real-time applications faster with a visual aid, not just for the programming, but for the visual representation of procedures as well.