Staged diagrams about penrose HOT 2 CLOSED

Keenan adds:

Basically we haven't addressed the temporal aspect of Penrose. The "worst solution except for all the rest" is WYSIWYG slideshow editors like PowerPoint and Keynote, which enable one to specify an ordering for events, and associate transitions with these orderings (which can also include specific timing directives). But just like laying out diagrams spatially, "laying out" diagrams temporally takes a lot of tedious, manual labor. [Personal note: I have spent hundreds of hours doing this in Keynote, and it is hell.] To add insult to injury, the strict ordering required by this paradigm puts artificial limitations on how staged diagrams can be "timed." A more powerful alternative is the timeline-based editing found in 2D packages like Adobe [Premiere|AfterEffects|Animate] or 3D packages like Blender and Maya. But this again requires meticulous hand-timing—even more than slideshow editors.

So, the main question is how to build the existing utility of Penrose out into the temporal domain. For instance, it makes a lot of sense to annotate Style rules with transition times and styles (e.g., a new point added to a diagram should fade in for 0.35 seconds). A very simple temporal ordering scheme could mimic the spatial ordering scheme we already have via the layer above/below keywords (so, perhaps, a show before/after construct). But then comes the question of how to deal with more complex synchronous events that can't be expressed via an ordering. For instance, one could expand these semantics into starts before and ends after. Etc. These are all "seed suggestions"—basically the point is that this design really needs to be fleshed out to be both simple but also general. I.e., it should line up with the same Penrose design goals stated in the paper, but just along the time axis. A beautiful thing that can happen here is that values like transition times and delay times can be optimized by the Penrose layout engine. Just as we currently might pack a set of graphical primitives onto the canvas, we can "pack" a set of events into a given interval of time, but still allow the programmer to specify which ones should be shorter/longer in a relative sense. [This is again something that I have tweaked meticulously by hand, and again, it is hell.]

See in-depth discussion in Slack thread here. Basically the conclusion so far is that timing rules should go in Style.

from penrose.

Closing. See: #1076.

from penrose.