For the jam, I worked on an experimental viewer for Metadesk files. Metadesk is a data description language, as well as a library for parsing and working with it, we made on the Dion team. It was originally made for metaprogramming in C. It was intended as a replacement for Data Desk, which is a tool I wrote a long time ago for the same purpose.

Not too long after we started Metadesk, we realized that our research from last year on the Dion Format continued being relevant while working on Metadesk, despite the seemingly large gap between the goals of the Dion Format, and a text-based metaprogramming data description language.

It turns out that Metadesk, while being a useful metaprogramming tool, also became a useful way to generically store structured data. It does this without imposing special meaning or ideas. This is one of the core differences between Data Desk and Metadesk - in Data Desk, there was a concept in the language for the idea of a struct. In Metadesk, there is no such thing, but the important structural properties of a struct are what it provides. So you can encode structs into Metadesk (as well as a whole lot more), without the language itself getting involved (other than providing some very common patterns of structure).

It gave us a lot of insight into certain problems that we've been facing on the Dion project since the beginning. How would the format store a variety of languages? How would it do version control? How would you mix multiple languages? Our idea of how to answer these questions became a lot clearer through our work on Metadesk.

Because Metadesk allows expression of generalized structured data (which is different from abstracting over various kinds of abstracted data), a Metadesk viewer - providing GUI for Metadesk trees - could provide GUI for many possible structures.

Let me explain. Imagine that you have N data formats, all providing tools for encoding a number of very field-specific concepts. Also imagine that these concepts can be functionally reduced to hierarchies, "slices" through those hierarchies (if this word is unclear, I recommend checking out our talk from last year), and metadata on those hierarchies.

These N data formats will differ not only in minute details, but also how they choose to compose various features, which features they define, which features they leave out, and so on.

The point is, though, that these N formats are all more specialized than a generalized format that allows encoding the same concepts. Because they are more specialized, the number of real programs - in the world - written to consume and work with these formats will be much smaller. What these formats are used to encode will be much smaller. There will be far less data stored in them than otherwise.

So, you can imagine that writing M different GUIs for each of these N formats results in writing N * M GUIs total. And, keep in mind, none of these GUIs will work together at all - someone would need to write conversion functions between the formats, this conversion may be lossy, and it will be a massive pain to take advantage of the fact that these formats are all, effectively, encoding the same things.

This does not need to be true with Metadesk - instead, the N file formats turn into N uses of Metadesk. The M GUIs are implemented on top of Metadesk, instead of the N usages of it. Therefore, you only have N + M GUIs to implement.

For sufficiently large N and M, the wins here are possibly massive.

Metadesk is not meaning to solve that problem - it retains its status as a metaprogramming tool that has been serving its purposes remarkably well - what I am describing is really my thoughts on what the Dion Format could provide, without being hamstrung by text.

So...big inhale...all that out of the way, I set off during the jam week (only getting a few part-time days in, unfortunately, some of which were streamed) to write a Metadesk viewer that tried out a few ideas relating to writing one GUI for many uses of Metadesk.

How is this "reinventing wheels"? Well, this is part of a big project to reinvent the way that we store all of our structured data. This includes code (as should be clear from the original Dion presentation), but it includes many other things as well - financial logs, structured journals, thought boards, picture libraries, and so on.

Ultimately, I wrote two primary GUIs: A text-hierarchy representation for the Metadesk data itself, and a grid of variably-sized image thumbnails that are rendered side-by-side with the Metadesk tree. I didn't get that much done, but let me explain why I am still so excited about this. :)

First, here's a demo.

This may first appear as a simple file explorer with image previews. And it is that, but the magic is that the code that implements this GUI can be applied to normal Metadesk data that is loaded in the viewer as well (I show this at the end).

What I did to cause this effect is I started with the Metadesk. First, I wrote a Metadesk visualizer, and a way to render thumbnails of images referred to by the Metadesk data (meaning that, if you had a text file that could be parsed as Metadesk that referenced an image - imagine some asset metadata for a game engine - the thumbnails would also exist there).

Then, to write the file explorer, all I had to do was - when in the "file explorer" mode - generate a Metadesk tree that encoded the directory hierarchy.

I used this "generate a Metadesk tree" trick for multiple things other than the file explorer, including UI for the help menu in the viewer, and command history. This also applies to regular Metadesk trees (that are generated by parsing a text file), obviously.

The same magic that happened with the image thumbnails, animation of the rendering, and so on, also happened with other features. For example, one feature I implemented during the jam was filtering based on Metadesk tags (which in the future I'd like to extend to a more general-purpose filtering system). That applies to all of these trees.

In other words, if some data can be reasonably encoded into a Metadesk structure, all of these GUIs now work for it.

I'm going to keep working on the Metadesk viewer past the end of the jam, since there's a lot more to explore, and I didn't get a full 7 days worth on the project. Namely, I'm going to be working on graphing values in a Metadesk tree (as scatter plots, histograms), visualizing table-like Metadesk data as actual tables, visualizing colors in the Metadesk data, using the viewer to do calculations with numbers in the data, and more.

This is just the beginning of what you can do with this, I feel, because it's not even getting to editor features. Coming up with the correct editor design for such a format is a difficult problem, and it wasn't something I wanted to try to solve during the jam, but there's a lot of magic to happen there as well.

Anyways, that's it!