Possible extensions to the image combinators

[yminsky]

One issue I see with the current image combinators is that the ability to overlay them seems limited. In particular, it's often natural to want to overlay some property over an existing image. For example, it would be nice to highlight a range of text by setting the background color attribute on some range of an existing image.

The current combinators offer no way of doing this cleanly, as far as I understand. To make it work, you basically need to get the correct attributes in when constructing the original image.

Would there be any interesting in adding some calls that would allow this kind of thing by operating more directly on images?

[rneswold]

This is similar to my request, #8, but more generalized.

[pqwy]

I was thinking about this a lot.

I was thinking more along the lines of combining attributes of overlaid images, but on one hand, it's not clear what the semantics would be, and on the other, the implementation would be both tricky and much slower (than this).

But now that I think about it, an operator to set the attributes on a region of a formed image should be doable.

I need to chew on it a little more. I think this can work out well.

[pqwy]

So... if you can set attributes on a region of the image, what falls out naturally is simply another image constructor screen : A.t -> int -> int -> image that produces a w * h rectangle with a particular attribute.

This rectangle renders like void, but when overlaid over another image, it changes the attributes of the cells below.

If it simply replaces what's below, that's too coarse. You couldn't make [####===] with different foregrounds, and then set the background in a single operation. It would force the foreground too.

So you need to compose the attributes per-cell. You also get

screen a1 w h </> screen a2 w n = screen (a2 ++ a1) w h

which is nice.

Then, both because it's impossible to recolour cells, and because this gets redundant, you remove attributes from the existing image constructors (and add attr: attr -> image -> image to compensate). Freshly constructed images all have no attributes.

Suddenly, explaining how this all fits together becomes much more involved. That, and when constructing images, you have to closely keep track of which regions have which attributes set and which are unset, as this affects image composition; say you create two distinct images, A and B, using screen to style A. If you do A </> B, wherever there are holes in A, there are visible cells of B with their attributes combined with A's.

An alternative is to introduce two distinct overlay operators, with only one combining the attributes.

And someone will surely demand to be able to remove attributes -- now you have negative attributes.

This can all be made to work, but it sounds tricky to use. That's what I mean when I say the semantics isn't quite clear.

[yminsky]

Yeah, I can see how pushing combination of attributes into the existing combinators for combining images could be tricky. The simple ability to edit attributes on existing images seems less fraught, since it doesn't change the underlying computational model in a material way; but it still gives you the power to build more interesting UIs.

[yminsky]

Related: another extension to the image combinators that would be useful would be the ability to mark the location of the cursor on a particular chunk of image. The downside is that if two images with cursors specified are combined, you're going to have to either fail or arbitrarily choose one. But the upside is that it lets you handle cursor placement in a more compositional way, so you could have a single widget that thinks about its own structure (including the placement of its cursor) embedded in a larger UI that just places it somewhere, without having to think carefully about cursor location.

[pqwy]

Here is something that might interest you.

It's a combinator to apply attributes to an image. It composes by refining, as opposed to overriding, the existing attributes.

And it works purely syntactically in the sense that it's defined over image terms, not spatial extents. But that is still sufficient to construct a function that applies attributes to a part of an image.

It came to be because I started using the library with images defined as attr -> image and operations lifted into the function space. The sane behaviour becomes very obvious in this domain.

[pqwy]

@rneswold Other than a thumbs-up, how does it work for you? Have you tried it out?

I'm asking because its behaviour might seem counter-intuitive at first glance.

[rneswold]

@pqwy, I read your comment yesterday and didn't get the impression that it had been committed; I thought you were proposing a new feature.

I'll update my OPAM repo and try it out.

[pqwy]

It's still on the attr branch.