Thoughts on comfortable GUI development
A.k.a. make Visual Basic happen again
Debugging
From research journal entry 2023-02-24.
When creating GUIs you might want to know:
- How is this element defined?
- Where does it come from?
- Why does it exist/am I seeing it?
From the entry as well:
[…] you should be able to enter a special mode while developing which allows you to click on a button and be taken to its editable definition. Editing that definition should either change that button (like the DOM editor in your browser) or all buttons (but that might render the current state impossible to reach?). Other things which would be cool is to know the causality of the button’s existence. E.g. which other buttons were pressed in the past to get to where we are?
It would be nice to achieve these features without hard coding them into the programming system. This requires meta-programming features. They also should have no performance impact if they’re not actually used, for example in a released program which doesn’t have to be inspectable.
Defining/editing graphically
Defining graphical user interfaces in code is not fun in my experience. The spooky action at a distance aspect of it kills experimentation and productivity. Therefore a programming system should have some way of defining programs that are part of version history in a programmatic way, so that a GUI editor can be implemented natively.
GUIs should be testable without relying on rendering
From journal entry UI designs/programs should be testable.
Could you record interactions with a UI and replay them in various contexts (resized windows etc.) so that they still work? This needs predictable identifiers for the UI components. What does a programming language which natively supports these predictable IDs look like?
In common OO programming object identity is not predictable, because the system is not pure and not replayable.
I think using a good denotation for causality will naturally lead to one for identity. Then you could use these identities to record interactions, independently of how GUI elements are actually rendered. The downside is that you can’t really test whether something is correctly layouted/visible, but I imagine many tests aren’t actually about that and more about general workflow.