I've made cassowary constraint solving for ultraviolet (like Ratatui)

[metafates]

Hello! I've made Cassowary constraint-solving (Wikipedia) implementation for ultraviolet.

I like how it is used in Ratatui framework and wanted something similar for Go.

So here it is, for anyone interested: https://github.com/metafates/uvcasso

TL;DR

func display(s *uv.TerminalScreen) {
	screen.Clear(s)

	var top, bottom uv.Rectangle

	uvcasso.Vertical(
		uvcasso.Fill(1),
		uvcasso.Len(1),
		uvcasso.Len(3),
	).
		Split(s.Bounds()).
		Assign(&top, nil, &bottom)

	// ^^^^^^^^^^^^^^^^^^^^^^^^^^^
	// The interesting part

	screen.FillArea(s, &uv.Cell{
		Content: "T",
		Width:   1,
	}, top)

	screen.FillArea(s, &uv.Cell{
		Content: "B",
		Width:   1,
	}, bottom)

	// Will fill the screen like this:
	// 1. Top part takes all available space
	// 2. Middle part takes exactly 1 line which we leave empty
	// 3. Bottom part takes exactly 3 lines

	/*
	   TTTTTTTTTTTTTTTT
	   TTTTTTTTTTTTTTTT
	   TTTTTTTTTTTTTTTT
	   TTTTTTTTTTTTTTTT
	   TTTTTTTTTTTTTTTT

	   BBBBBBBBBBBBBBBB
	   BBBBBBBBBBBBBBBB
	   BBBBBBBBBBBBBBBB
	*/

	s.Render()
	s.Flush()
}

[aymanbagabas]

@metafates This is such great work! Thank you so much for working on this 🙂

I looked at this some time ago, but never had the time to work on it. It would be wonderful to upstream this into Ultraviolet layout subpackage.

[metafates]

Thank you! I'll open a MR soon then

[jaypipes]

@aymanbagabas @metafates while I appreciate the elegance of the cassowary constraint solver (nice :) ), I don't actually care for the API introduced here in the ultraviolet layout/ package. One of the things I don't particularly like about lipgloss is the whole join-horizontal, join-vertical APIs for doing "layout-y" stuff. I prefer more of a HTML+CSS-like API where you declare the positioning, display and alignment attributes of elements individually instead of requiring the user to essentially construct the entire layout grid in a single object like the uvcasso.Vertical() function (and the Layout's Split and Assign methods require).

I guess this all goes back to a question of how low-level you envision the ultraviolet library to be when it comes to housing code for doing things like plotting, coordinates, layout, text and block alignment, etc. @aymanbagabas do you have anywhere where you've jotted down your thoughts on the dividing line for what should be in ultraviolet versus what should be in either other libraries?

[aymanbagabas]

Hey @jaypipes, the layout package implements the cassowary algorithm and provides a way to construct layouts using a nice API that is relevant to how terminals work. You can still use it to create an HTML+CSS layout API I imagine.

I envision Ultraviolet to be an imperative TUI library that helps to build TUI applications and frameworks. Right now, it powers Bubble Tea v2 and Crush. The library is still missing many primitives, like a basic type for building text and block components. In terms of plotting, coordinates, and layouts, these are already possible with the existing API. For example, Ultraviolet has a window system that can be used to have isolated window screen buffers. You can start with a root window, and plot sub windows on top before rendering the diffs and changes. Ultraviolet uses a simple 0-based X/Y coordinate system for cells. Wide cells have trailing "empty cells" after.

I would love to hear how you envision Ultraviolet and what you would like to see in Ultraviolet as library?

[jaypipes]

@aymanbagabas yes, I'm familiar with ultraviolet's API (though I must say, it's changed dramatically over the last 4-5 months or so in lots of breaking ways). I built a library on top of ultraviolet primitives like Screen and Border before the API changed and broke my library :)

My point was more that it's been tough to rely on ultraviolet at this point as an underlying library because it's just not clear where the dividing line is between ultraviolet and other things and the API keeps changing without warning in pretty dramatic ways. I understand there are warnings in the README about ultraviolet being not stable, so I'm not complaining about that at all. But, to use Ratatui as an analogy, Ratatui has this concept of supporting multiple "backends" that handle the low-level terminal I/O and event handling. I was thinking that ultraviolet was going to be more like the crossterm backend and less Ratatui itself. I thought something like Bubbletea was more analogous to Ratatui and ultraviolet was more analogous to the crossterm backend. Which is why I was asking you about where you saw the dividing line between ultraviolet and other things was.

I guess I'm looking for more of a crossterm backend than a ratatui :)

[jaypipes]

Also, you wrote:

provides a way to construct layouts using a nice API that is relevant to how terminals work'

I'm not sure what you mean by "that is relevant to how terminals work"? The API that was merged into ultraviolet's layout package is verbatim copied from the ratatui-core layout crate. I don't see how Vertical(), Horizontal() and Split() are "relevant to how terminals work" compared to a layout model that uses a tree-based system for laying out adjacent bounding boxes. For what it's worth, Taffy is a Rust layout system that uses a tree-based system for laying out boxes on a screen and the Ratatui contributors strongly considered adding support to Ratatui for Taffy as a layout engine because it was seen as a more natural way for developers to describe layouts...