This is the first kind of UI "component" which requires state that is separate from the application.

For that:

• A component model is needed, so that the application is free of handling view states.
• Before rendered, the view component's states must be able to be adjusted by the application's render step. (aka. vetoing).
• The components need to be scoped.

  I considered something in the realm of topo, but the macros are scary and lack IDE support, also I feel that scope should be defined by the application and not related in any way to the call stack, well, even though lambdas will probably be needed?
  Because a rendering context needs to be provided to render only what's visible, extending that with scoping and lookup functionality should not be that hard.

I think this will be one of the most important additions to the UI framework.

It will enable:

• Extensible and composable UI components including layout containers, etc.

  I don't actually like layout containers, or any hierarchical UIs for that matter, but it seems the easiest way to be specified and in general "computed" compared to a relational model, so I go along with that until something better comes around considering that constraint systems behave somewhat strange in terms of performance and determinism and introduce a level of complexity I don't want anyone to be forced into.

It may enable or at least prepare for:

• Zooming UI functionality (lazy / on demand rendering, i.e. level of detail).
• A proper way to define animations.

This happens when a window was placed and saved on a secondary screen, and the screen was disconnected before starting emergent again.

After thinking weeks about a suitable component model (#50) and taking a look at several of them, I now think that user interfaces don't need a component model, or at least not a predefined one.

It seems to me that each application has different requirements, which a component system often can not foresee.

Component systems are provided for two reasons:

1. to have abstract names and functionality for things. E.g. a button is an abstraction for a layouted text area with an input area for recognizing touches.
2. to be able to optimize away in case parts do not change between frames.

But from my experience, a predefined abstraction breaks down a lot sooner than it may be anticipated. E.g. as soon we define a button to contain a layouted text, an application needs a button that contains somethings else, like a custom drawing that changes with the size of the button.

So, I've decided to focus on the second part first and let the actual "components" emerge by building a solid foundation for UI rendering. This includes primitives for

• frame caching, for example to avoid recomputing layouts.
• relational dependency graphs, for matrices and coordinate systems, global layout dependencies, or styles maybe (CSS like)?.
• level of detail management, on demand rendering of details depending on zoom levels.
• clipping for culling the content in scrolling areas, for example.
• parallelization for computing text layouts, for example.
• performance measuring for finding out how to make the UI display faster.

Now seeing that list, I wish I had these primitives available in several UI frameworks before, but they always seemed to be hidden behind the - rigidly feeling - "component system", making it very hard to realize specific requirements with it.

So what I want to attempt is to build a set of primitives with which it is possible to create a component system, but also can be used to create an optimized application specific presentation renderer.

I've read somewhere that f32 is quite limiting for the representation of larger gaming worlds. Although I don't think that this is usually needed for user interfaces, one could imagine that a large zooming canvas would reach floating point limits sooner than expected.

Not sure how this affects the Skia backend though.

When moving the testrunner window from one monitor to another, the DPI resolution of the fonts are not adjusted.

half.rs looks like a proper contender for a suitable implementation:

https://github.com/starkat99/half-rs

... because the current DPI is part of the environment parameterization the Presentations are generated with.

Not recreating the presentation may cause layouting problems when a window is moved from one screen to another one with a different resolution.

This is needed to layout drawings of test run results in the testrunner.

A println! is really convenient to get some values out of the testcase while a live testing session is active.

Time to get interactive.

Right now, tap gestures are required to be able..

• to tap on a filename in the compiler message to open the IDE at that point.

  postponed

• to collapse individual testcases or modules.

The plan:

• Introduce the concept of area markers in the drawings. These are markers representing drawing rectangles that are computed with the *FastBounds trait family. #31
• Then a new type called Presentation is used as the default output of a testcase and an application. A Presentation combines drawings, gesture detection requests based on area markers, and event template serialization. #31
• Introduce a new package emergent-presentation in the subfolder presentation/ (#31):
  • Support event templates. These are the events an application may receive, including holes to fill in additional information. The holes may be filled in by convention, or generic types?

    not needed anymore, see blow.

  • Support for visualizing presentations: This should include the gestures requested, the event templates and the markers involved.

    Basic visualization is implemented, but named areas and scopes must be added.

Issues:

• If monotonically increasing unique ids are used to represent the markers, how can snapshot testing be supported for the output of individual testcases?

  not needed, &'static strs are used up area identities by introducing namespaces / scopes.

• Can event templates be strongly typed so that the information the gesture detector may provide be mapped to them? Of course all fields are optional. For example a tap gesture detector may provide taps_count, positions, position (the first one), global_positions screen relative position, etc.
  One idea is to provide a (pure!) function that takes the arguments of the recognizer state. The serializer creates a arbibtrary marker state, calls the function with it, and then replaces the values that survived with references that are filled in later.

  Not using templates anymore, the part of the presentation that cannot be serialized stays inside the WindowApplication wrapper.

• How can the returned positions be mapped to other elements / drawing areas from within the application?

  Postponed.

Because the WindowApplication receives all events winit is sending through, a re-render happens as soon the mouse is moved over the application window.

This can be solved by a scene-graph diff, which is probably needed anyway as soon render caches are in use.

That would keep the fields accessible without going through getter functions and minimize the serialized footprint at the same time.

https://github.com/kardeiz/serde_tuple

Sidenote: Serialization is not considered compatible between different versions of emergent. This conflicts a bit with my plan to use snapshot testing. So, if the format changes, snapshots would need to be regenerated.

I think we need both, snapshot testing based on the serialized representation of a drawing, and image snapshots for an additional visual comparison. And for both, a visualization of the differences are needed in the testrunner.

The testrunner should also be able to visualize compiler errors and warnings to assist for refactorings.

The first step in this direction landed already in master. Using the cargo_metadata crate, cargo and rustc output is converted into CompilerMessages and can be processed from there.

The next step is to support to render text runs and use Skia's text shaping for measuring and layouting UTF8 text.