|
|
| Line 1: |
Line 1: |
| ==Overview==
| | {{to wooz}} |
| I/O Markup Language is intended as a language for specifying any kind of interface, more or less. There are probably other languages which purport to serve the same purpose (e.g. [[wikipedia:XUL|XUL]], but it remains to be seen whether these work the way I see IOML working, or can be adapted to do so.
| |
| | |
| Until I have time to look carefully at XUL and/or begin more detailed specifications for IOML, I'm collecting reasons why [[HTML Is Broken]].
| |
| ==Some details==
| |
| I'd like to see a multi-layered approach, ranging from the most basic operations (drawing pixels on the screen) to the highest (real-time interactivity outside of individual components, client data handling...).
| |
| | |
| Instructions in all layers are specified in human-readable text instructions, though they can be ''somewhat'' cryptic in order to keep things simple and fast. I'm not sure exactly how the "reading" functions would work in this context, but several possible methodologies suggest themselves, so I doubt it's going to turn out to be a huge problem.
| |
| | |
| The fact that everything is in layers means that part of the application can run on a remote server, much like a "web application", but the flexibility of IOML means that the level of interactivity can be much more like a "normal" desktop application. You also have more power to specify where the computation takes place, as the language is not restricted to "talking" at just one level the way HTML or JavaScript is. Commands can be addressed to any layer, though the server has the option of blocking any set of commands it deems "unsafe".
| |
| ===Bottom Layer===
| |
| This layer handles the basic pixel-and-screen operations in a device-independent way. It can:
| |
| * draw pixels
| |
| * draw common shapes (rectangles, anti-aliased lines and curves)
| |
| * return current pixel values
| |
| * return screen capabilities (dimensions, pixel depth, type of device {screen, printer, projector}, physical resolution (dpi)...)
| |
| | |
| Support for multiple layers and an alpha component would make sense but is probably not necessary for a usable implementation.
| |
| | |
| Because of speed issues, there might be a more direct "binary"/"C-style" API at this level as an alternative.
| |
| ===Text Layer/Subsystem===
| |
| * draw text in a specified font
| |
| * return metrics of printed or hypothetical text
| |
| ===Component Layer===
| |
| This layer handles the drawing and animating of common components, like those found in most graphical IDEs:
| |
| * Static text
| |
| * Edit box
| |
| * Combo (drop-down list) box
| |
| * Listbox
| |
| * Treeview
| |
| A command-block at this level might specify, for example, a dialog box, including the location of each control and what other command-blocks to invoke when the user interacts with each control.
| |
| ===Data Layer/Subsystem===
| |
| Handles interaction with databases (many IDEs handle this sort of thing with "invisible" components, so this is probably quite similar to the Component Layer).
| |
| ===Application Layer===
| |
| This is the layer where purposeful stuff happens -- the glue language that tells all the other pieces what to do.
| |
| | |
| There may be other layers and details I'm missing; this is just written off the top of my head while eating dinner.
| |
| ==Notes==
| |
| The description for '''hsc''' ("HTML Sucks Completely") sounds like it might be similar to IOML on some levels, and especially like the markup language I actually implemented for generating data-driven static pages on vbz.net: "It can be used on any HTML file and creates a new HTML file as output. In the input file, you may use an extended syntax based on HTML, which allows for things like macros, conditionals, variables, expressions etc." Vbz's language was specifically designed for pulling data from a relational database; I don't know if hsc can do this or not.
| |
