Proposal: FlexLayout, Flexible widget, TextBaseline, ....

[fpabl0]

Description:

It seems that Fyne needs more powerful containers/layouts to create more beautiful widgets with different sizes (related to #1701). This proposal include a FlexLayout that is divided in two main layouts Row and Column, its implementation is heavily based on Flutter's Row and Column widgets. These new layouts will accept two parameters MainAxisAlignment and CrossAxisAlignment where the user can specify how to align the objects inside it.

There would be two new widgets called Flexible and Expanded that will help these new layouts to know the flex factor desired.

New common methods for all existing widgets are required or maybe just an independent interface?? Every widget should have two methods:

func DistanceToTextBaseLine() float32 Used for Row layout to align objects based on the text baseline.
func String() string or func Name() string Used for FlexLayout for debug purposes.

This PR is currently a draft should be improved and needs some decisions on current widgets, suggestions are very welcome :)

Some screenshots:

• CrossAxisAlignmentStart

• CrossAxisAlignmentEnd

• CrossAxisAlignmentCenter

• CrossAxisAlignmentBaseline

• Responsive layout

flexlayout_responsive.mp4

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

Where applicable:

• Public APIs match existing style.
• Any breaking changes have a deprecation path or have been discussed.

[andydotxyz]

Is CrossAxisAlignment basically a VerticalAlignment? cross-axis applies specifically to this sort of layout, but I wonder if these sorts of alignments could be useful elsewhere.

p.s. Adding String to the Widget interface for debugging is really not needed - there is a Stringer interface already and you can do a type assertion to use it on widgets that support :).
That said given that this relates to alignment I wonder if the functionality belongs on WidgetRenderer instead?

I think I need to write up a document about our current-state of alignment / padding so we can understand it better.
horizontal alignment (though a lot easier) is handled quite well without needing specific layouts to support it - so I hope we can attain something similar for vertical. (i.e. container.NewHBox would probably benefit from such help).

[fpabl0]

Is CrossAxisAlignment basically a VerticalAlignment?

No, it depends of what Axis you choose. Axis can be horizontal or vertical. I haven't organized very well the code in this draft as I have locally, so when I upload the changes maybe it will more clear.

p.s. Adding String to the Widget interface for debugging is really not needed - there is a Stringer interface already and you can do a type assertion to use it on widgets that support :).

Yeah, I proposed it just for a problem I had, but I have solved it, so it's not needed now.

horizontal alignment (though a lot easier) is handled quite well without needing specific layouts to support it - so I hope we can attain something similar for vertical. (i.e. container.NewHBox would probably benefit from such help).

I haven't uploaded last changes I have locally yet, but basically now Row container can work as container.HBox (but in a more powerful way), and it is the same for the proposed Column container and the existing container.VBox

[fpabl0]

@andydotxyz I have just updated! :)

[andydotxyz]

This is a lot of constants, all added to the top level, to support 1 layout?
I also don't understand how cross-axis align is the only one that has baseline, but in a previous comment you said that this does not equate to vertical alignment.
If it is interchangable why do the cross-axis and main-axis constants have vertical and horizontal specific elements?

In general it feels like this is bringing a layout and API in from Flutter instead of finding a way to match and extend the Fyne design. It should be possible to get the benefits of baseline alignment with a lot less extra API.

[fpabl0]

@andydotxyz

This is a lot of constants, all added to the top level, to support 1 layout?

Yes, that's a fair point. But as the constants names are general, maybe it can be useful for other things maybe in the future? Otherwise, they can be inside layout package but it will look weird, I think.

I also don't understand how cross-axis align is the only one that has baseline, but in a previous comment you said that this does not equate to vertical alignment.

Cross-Axis is not vertical alignment, however baseline is only possible when Cross-Axis is the vertical one, when Cross-Axis is the horizontal one it will do the same as CrossAxisAlignmentStart. It is necessary to have different constants because as you can see only the MainAxisAlignment has SpaceAround, SpaceEvenly and SpaceBetween options.

If it is interchangable why do the cross-axis and main-axis constants have vertical and horizontal specific elements?

Only Baseline is specific, and for Cross-Axis Horizontal as I said above, it will means CrossAxisAlignmentStart.

In general it feels like this is bringing a layout and API in from Flutter instead of finding a way to match and extend the Fyne design.

I don't think so, for flutter all the things are widgets, for Fyne it is not. That's why I define FlexLayout in layout package implementing the Fyne Layout interface. I am just extending Fyne layout package.

It should be possible to get the benefits of baseline alignment with a lot less extra API.

It is not only about baseline alignment, it is about of axis alignment in general. Currently, Fyne does not provide any axis alignment, as far as I know (sorry if I am wrong).

[andydotxyz]

Can we re-visit the additional functionlity with the smallest possible additional API?
Until we see how this cannot be supported by just a layout's configuration it is not clear why all the top level APIs are desirable.

[fpabl0]

Can we re-visit the additional functionlity with the smallest possible additional API?

Yes, we can. However, I don't understand very well what the part smallest possible additional API means. Axis type and constant options, to be honest, are not really needed (just MainAxisAlignment and CrossAxisAlignment are required) so that part can be removed. I think there are 2 options to add this functionality:

1. modify container.NewVBox and container.NewHBox, to accept the new functionality, however it would be a breaking change, and they would also need MainAxisAlignment and CrossAxisAlignment constants to configure them.

2. Add new containers container.NewRow and container.NewColumn and deprecate VBox and HBox, so there is no breaking change.

That's the only two options I have in mind, but maybe I am missing something, have you though in any other? If yes, please let me know and I will try to implement it :)

all the top level APIs are desirable.

What do you mean? You mean the top level constants?

[andydotxyz]

Your idea about adding support for better alignment in VBox and HBox is an interesting one - do you have a feeling for how that might look?
I would imagine it could be done without breaking changes if any additional features default to current behaviour.

all the top level APIs are desirable.

What do you mean? You mean the top level constants?

The top-leve ones worry me the most yes. The Fyne package is for domain types - something used only in one package (and especially only for a single type) probably does not belong here.

[fpabl0]

@andydotxyz

Your idea about adding support for better alignment in VBox and HBox is an interesting one - do you have a feeling for how that might look?

Yes, there could be a new constructor called NewXBoxWithOpts or NewXBoxWithAlignment (although this last one is more descriptive, it is maybe a too large name?), then NewVBox/NewHBox can continue existing with a default behavior.

I would imagine it could be done without breaking changes if any additional features default to current behaviour.

Yes, that's a possibility. However I am worried about that the default behavior is all expanded, with the proposed implementation here, the expansion is optional by wrapping the widgets into a new widget called Flexible (I have implemented it in widget package but it can be moved to layout package as it does not do anything without a layout just like layout.Spacer), so to force the default behavior, it means internally we would need to wrap all passed CanvasObjects with a Flexible widget, and it will break somethings, for example: the visibility functionality because if user wants to hide a widget passed to the container, it won't really work, because it will hide the widget inside Flexible but not the Flexible widget.

However, I think this last problem is just related of how I have implemented Flexible widget, maybe I could force the Flexible widget to track the the visibility of its child widget? (although I don't think it is possible, because it would mean that a child is modifying its parent). Another possibility is to simply extract the object, held by the FlexibleWidget, inside Layout method of the V/HBox layout and check the visibility from it and not from the FlexibleWidget. What do you think?

The top-leve ones worry me the most yes. The Fyne package is for domain types - something used only in one package (and especially only for a single type) probably does not belong here.

I see, good point, so maybe these new types should live in Layout package.

[andydotxyz]

However, I think this last problem is just related of how I have implemented Flexible widget

I did not notice the flexible widget before - what is its purpose?
Widgets provide functionality and layouts provide the size/position for containers.
The addition of Flexible sounds like it would break the layout algorithms of other containers - but I don't really understand what it is so I could be wrong.

[andydotxyz]

There would be two new widgets called Flexible and Expanded that will help these new layouts to know the flex factor desired.

We have avoided putting metadata on widgets to control layout algorithm - this is not how the container / layout API is designed to work.
All widgets will expand to the space available - perhaps this ticket needs to articulate why that is not sufficient, and what it does to fix the specific problem. Introducing it as "Fyne needs more powerful containers/layouts" does not explain to me what the solution will do. It also is not clear how this differs from #4 or #47.

[fpabl0]

Widgets provide functionality and layouts provide the size/position for containers.

Yes, that's why I said later that it could live inside layout package as it is not exactly a widget (just like layout.Spacer).

The addition of Flexible sounds like it would break the layout algorithms of other containers

I don't see why it would break current layout algorithms as it would be the same as layout.Spacer.

perhaps this ticket needs to articulate why that is not sufficient, and what it does to fix the specific problem.

Ok, let's suppose you are trying to build this layout:

If you do it with the current VBox and HBox, you are going to get this:

With Grid Layout:

To get the desired behavior you will have to create a custom or extended widget. But with the proposed layout it isn't needed.

Maybe there are other easier ways to accomplish this situation that I am not seeing, so I could be wrong (sorry if my appreciations are wrong, I just want to help). This situation maybe is not really useful, and for the most use cases I think you are right, expanded by default is the direction Fyne should go.

I think the most useful part in this draft is the CrossAxisAlignment (specially to solve the problem about the widget baselines), so maybe it is possible to add at least that functionality to the current VBox/HBox or Grid layouts, what do you think?

Introducing it as "Fyne needs more powerful containers/layouts" does not explain to me what the solution will do.

This solution will solve the problem that we cannot have different widget's heights or widths because current layouts don't do cross axis alignment.

It also is not clear how this differs from #4 or #47.

Sorry, I don't get it. #4 and #47 are unsolved issues not solutions. Cassowary algorithm seems to be more complex and not user friendly (maybe I am wrong, it is the first time I heard about it and looking out for examples of it, it doesn't seem to be very friendly). As an internal layout engine sounds a great idea, but maybe it will take too much time, won't it?

[andydotxyz]

You are quite right what you desire to do cannot be accomplished with VBox and HBox. They are designed to pack widgets into vertical or horizontal boxes with the smallest space possible while looking good. To have elements stretch you would need a different layout/container. Consider using Border for each row and it will work perfectly. You can see all the built in options at https://developer.fyne.io/started/layouts.

To focus this on “HBox does not support baseline alignment” does sound like a good idea and it solves a clearly defined problem.
I linked the other tickets because they ask aim to create more complex/powerful layout systems which this ticket seemed to open with saying was needed. Sorry for the meandering nature of some of these comments but I think we have explored well what needs to be fixed can what could be added to in the future. Clearer scope of PRs makes it much easier to see what the minimal change would be :).

[fpabl0]

Consider using Border for each row and it will work perfectly.

It works better, but not perfect unfortunately:

The icon is expanded to match the Entry height. Although this could be solved by increasing the size of the icon it is not what the user initially wanted.

To focus this on “HBox does not support baseline alignment” does sound like a good idea and it solves a clearly defined problem.

Yes, but I have just realized that Border, HBox, VBox and Grid expand by default the cross axis, so no cross axis alignment can be done on them, at least not without breaking changes. Currently, it does not seem to be a big problem because all widgets have similar sizes, however it will limit the possibilities to add new ones with different sizes, isn't it?

I linked the other tickets because they ask aim to create more complex/powerful layout systems which this ticket seemed to open with saying was needed.

Got it, but I don't think they talked about the CrossAxisAlignment. #47 was an effort to bring web FlexBox design to Fyne, and it is focused on flex properties. #4 is great, but it was opened on 2018, it has been passed almost 3 years now, maybe an intermediate solution could be great? I have tried to find Cassowary implementations but could not find a many of them, python's one seems to be the best one (although this project is being dusted off as it states here: https://pypi.org/project/cassowary/) Who is using Cassowary algorithm now days? I would like to try it, it looks complex but great and powerful.

Sorry for the meandering nature of some of these comments but I think we have explored well what needs to be fixed can what could be added to in the future.

No worries.

Clearer scope of PRs makes it much easier to see what the minimal change would be :).

You are right, sorry about that. I thought it would be great to have a solution that covers not just one problem, but others too; however it resulted in a confusing proposal, really sorry.

[andydotxyz]

The icon is expanded to match the Entry height.

mid you wish to avoid an element expanding you can place it in another container, perhaps container.Center.

Yes, but I have just realized that Border, HBox, VBox and Grid expand by default the cross axis, so no cross axis alignment can be done on them

Indeed, this seems to be the crux of the matter. What the minimal approach to fixing this is what I am interested in drilling down to. VBox fills horizontally and HBox fills vertically - but an additional api that makes this configurable could be a possibility?

cassowary is what iOS (and some Android?) use for their app layouts (auto-layout is another name). If this ticket is to be focused on baseline alignment then I agree the other tickets done encapsulate the improvement.

[fpabl0]

mid you wish to avoid an element expanding you can place it in another container, perhaps container.Center.

You are right, that solves the problem 🥳. However, it seems like a workaround solution instead of a solid one? I mean, it was not really clear (at least for me) how to reach to that solution. But maybe it is because I am not very familiar with Fyne layouts. Nevertheless, considering that some of the people who come here, have background experience with other frameworks/toolkits, it might be a little hard to figure out how to accomplish some common tasks they used to use.

Indeed, this seems to be the crux of the matter. What the minimal approach to fixing this is what I am interested in drilling down to. VBox fills horizontally and HBox fills vertically - but an additional api that makes this configurable could be a possibility?

Yes, that's a possibility. There could be NewXBoxWithCrossAlignment() and then have CrossAlignmentStart, CrossAlignmentEnd, CrossAlignmentCenter and CrossAlignmentBaseline (I removed Axis word because it makes it look too large, but maybe with Axis is more clear?). However, this change should modify the behavior of BorderLayout, I mean it should have alignment too, shouldn't it? And what about the Grid? It should have that kind of alignment too? So, as far as I can see, this movement would change almost all the current layouts. It might be easier if there are just two main layouts that can build all others?

For example, VBox and GridWithRows are related and HBox and GridWithColums too, the only difference is that the XBox variant keeps main axis min size and GridWithX expands the main axis, but it's not clear by looking at their names (although it is very clear in the documentation). Why couldn't they be just variants of one main layout?

Sorry, for all these questions.

cassowary is what iOS (and some Android?) use for their app layouts (auto-layout is another name).

Oh I see, I have no experience in iOS native development. I have a bit experience in Android native development, and it has some kinds of constraint layouts (indeed there is a layout called Constraint, IIRC), but to be honest, I didn't like it, it was hard to align elements (the relativity is great until you want to remove or hide an element or make a specific element work different from others without actually impacting the others). Indeed, that's one of the reasons that led me to migrate to hybrid solutions first Ionic, and finally Flutter.

[andydotxyz]

However, it seems like a workaround solution instead of a solid one?

I don't understand why. As with the rest of Fyne the API it is designed to be simple whilst supporting complex solutions can by combining elements. You can see this in action at the end of https://developer.fyne.io/started/layouts page.

some of the people who come here, have background experience with other frameworks/toolkits

This is true - but given that every toolkit has their own way of handling layouts I don't think it makes sense to implement a huge variety of APIs to accomidate this. We have had requests for CSS and Java layouts too - but when it's a different approach we have decided not to. The Cassowary could be considered as it is self-contained as a single layout (though as you noticed it has not been implemented because we found it's not really needed).

This is why I want to focus on what cannot be done, so we can fix / add support with focus.
Design decisions can also be reviewed as well, but probably not in a PR.

this change should modify the behavior of BorderLayout, I mean it should have alignment too, shouldn't it?

I don't think so - it is designed to stretch elements along the sides. elements on the edges will surely have more than a single baseline?

Why couldn't they be just variants of one main layout?

All our layouts could have been defined by a single system (Like cassowary #4) but we decided to make a more semantic API, such as grid, border etc, that covers many cases with trivial amounts of developer code in comparison.

but to be honest, I didn't like it, it was hard to align elements

Indeed, hence our semantic API based approach.

[fpabl0]

I don't understand why. As with the rest of Fyne the API it is designed to be simple whilst supporting complex solutions can by combining elements.

Because in the previous example, I don't want specifically to center the icon, I just wanted to avoid it to be expanded.

but given that every toolkit has their own way of handling layouts I don't think it makes sense to implement a huge variety of APIs to accomidate this.

I am agreed with this.

Design decisions can also be reviewed as well, but probably not in a PR.

Fair enough.

I don't think so - it is designed to stretch elements along the sides. elements on the edges will surely have more than a single baseline?

If we put a text based widget in the border layout, definitely we need some alignment, don't we? And what about Grid layouts, they should have CrossAlignment too, shouldn't them?

we decided to make a more semantic API, such as grid, border etc, that covers many cases with trivial amounts of developer code in comparison.

Yes, that's a good decision. However considering Grid (WithColumns and WithRows) is used in almost all other frameworks in the same way, is a bit confusing that Fyne use them different, specially when we compare them with VBox/HBox layout, however as you said, this need to be talked outside a PR.

Indeed, hence our semantic API based approach.

Yes, that's good :)

[andydotxyz]

Because in the previous example, I don't want specifically to center the icon, I just wanted to avoid it to be expanded.

Indeed - but not expanded in what way? centered, vertical top or bottom etc are all possible with different layouts (i.e. VBox and a Spacer could cover the other two).

If we put a text based widget in the border layout, definitely we need some alignment, don't we?

I was imagining that it will more likely be a multiple line element as borders are most commonly used for the whole app.

And what about Grid layouts, they should have CrossAlignment too, shouldn't them?

Quite possibly. If this becomes about fixing the alignment of various layouts then the location of the constants would need to be considered carefully (like the text alignment).

[fpabl0]

Indeed - but not expanded in what way? centered, vertical top or bottom etc are all possible with different layouts (i.e. VBox and a Spacer could cover the other two).

Yes, you are right. I have just realized it, thanks :). Although it seems that it involves many different layouts that make the solution be a bit confusing and a bit hard to figure out how to accomplish it, but again that could be because I am not very familiarized with it.

borders are most commonly used for the whole app.

Yes, that's why I told you that at least for me, the previous solution (that use BorderLayout) looks more like a workaround instead of a direct solution.

Quite possibly. If this becomes about fixing the alignment of various layouts then the location of the constants would need to be considered carefully (like the text alignment).

Yes, it is possible, where could we discuss these design considerations? I wonder if there could be something like container.NewExpandedXBox (similar to container.NewGridWithX behavior). With this new constructor for XBox, BoxLayout could be used for a lot of things (without the need to actually use a Grid). Then we could have CrossAlignment just for BoxLayouts:

CrossAlignmentStart
CrossAlignmentCenter
CrossAlignmentEnd
CrossAlignmentBaseline
CrossAlignmentExpand or CrossAlignmentStretch (default one, and current behavior)

[fpabl0]

After playing with layouts, I managed to implement the previous proposal:

func proposed() fyne.CanvasObject {
	return newVBox(
		pRow(theme.ComputerIcon()),
		pRow(theme.DocumentIcon()),
		pRow(theme.MailComposeIcon()),
	)
}

func pRow(res fyne.Resource) fyne.CanvasObject {
	img := canvas.NewImageFromResource(res)
	img.SetMinSize(fyne.NewSize(theme.IconInlineSize(), theme.IconInlineSize()))
	return newHBoxWithAlignment(layout.CrossAlignmentCenter, img, newExpandedHBox(widget.NewEntry()))
}

The above code is equivalent to:

func current() fyne.CanvasObject {
	return container.NewVBox(
		cRow(theme.ComputerIcon()),
		cRow(theme.DocumentIcon()),
		cRow(theme.MailComposeIcon()),
	)
}

func cRow(res fyne.Resource) fyne.CanvasObject {
	img := canvas.NewImageFromResource(res)
	img.SetMinSize(fyne.NewSize(theme.IconInlineSize(), theme.IconInlineSize()))
	return container.NewBorder(nil, nil, container.NewCenter(img), nil, widget.NewEntry())
}

So basically, the proposal is to keep the current container.NewVBox and container.NewHBox and adding:

container.NewVBoxWithAlignment
container.NewHBoxWithAlignment

container.NewExpandedVBox
container.NewExpandedVBoxWithAlignment
container.NewExpandedHBox
container.NewExpandedHBoxWithAlignment

Expanded containers make the children have the same size along the main axis (just like container.NewGridWithColumns and container.NewGridWithRows)

[andydotxyz]

Yes, it is possible, where could we discuss these design considerations?

Normally large changes take the form of a proposal: https://github.com/fyne-io/fyne/wiki/Contributing:-Proposals
With regards to "CrossAxisAlignment" I don't see the benefit of not specifying which axis an alignment applies to - horizontal or vertical. Also we use "Leading" to mean left and "Trailing" for right when it refers to text for future support for right-to-left.

I don't understand the addition of "Expanded" or "Stretch" - I think that is confusing how small elements could fit within a larger space compared to widgets filling space and arranging their content.
Fyne layouts ensure space is avaialble for their child objects - alignment happens within that space. I don't quite know what the implication of that is for your proposal, perhaps that would be covered when a proposal is created?

newExpandedHBox(widget.NewEntry())

All widgets will expand when asked to... Adding an ExpandHBox will add confusion to this matter IMHO.
The box widgets are designed to pack content - not to expand it. I think we have a misunderstanding of the purpose of core widgets that could be adding confusion to the proposal that could come from this PR.

[fpabl0]

Normally large changes take the form of a proposal: https://github.com/fyne-io/fyne/wiki/Contributing:-Proposals

Got it.

With regards to "CrossAxisAlignment" I don't see the benefit of not specifying which axis an alignment applies to - horizontal or vertical.

Well, if we do it (using horizontal and vertical), we would have 7 constants, while we could have just 4 (if group in as CrossAxisAlignment). It also simplifies the internal implementation of boxLayout (we just need to be aware of 4 alignments instead of 7).

Also we use "Leading" to mean left and "Trailing" for right when it refers to text for future support for right-to-left.

Ok, now I am lost. CrossAxisAlignmentStart and CrossAxisAlignmentEnd have nothing specific for text, the only alignment option that refers for text is the CrossAxisAlignmentBaseline. But if you are trying to say that Leading and Trailing are common words for start and end alignment in Fyne, then it's totally fair, and these options could be renamed to CrossAxisAlignmentLeading and CrossAxisAlignmentTrailing, that's fine :)

I don't understand the addition of "Expanded" or "Stretch" - I think that is confusing how small elements could fit within a larger space compared to widgets filling space and arranging their content.

You mean this part [CrossAlignmentExpand or CrossAlignmentStretch]?. If yes, then I don't know how it is confusing, if that is the actual way how VBox and HBox works, I added that alignment just to match the current behavior.

Adding an ExpandHBox will add confusion to this matter IMHO.

Hmm I really don't understand. ExpandedHBox would work just like GridWithRows but without writing the number of rows.

The box widgets

You mean box layouts?

The box widgets are designed to pack content - not to expand it.

Yes, current Fyne layout's behavior is: VBox/HBox expand cross axis while GridWithRows/GridWithColumns expand main axis. The addition of VBoxExpanded/HBoxExpanded would expand main axis just like GridWithX, so boxLayouts would have both possibilities, and then we don't need to add alignment to any other layout just for boxLayouts as they would cover almost any disposition.

[andydotxyz]

GridWithRows/GridWithColumns expand main axis.

The grid widget expands in both dimensions. Most layouts do. Box is special in that it tries to compact on the main axis.

You mean this part [CrossAlignmentExpand or CrossAlignmentStretch]?. If yes, then I don't know how it is confusing

Because the default for layouts is to expand/stretch - in our other usage of the word Alignment it is to specify how something fits within the space.

[fpabl0]

The grid widget expands in both dimensions.

Yes, good catch. I have put all these considerations in the wiki proposal page: https://github.com/fyne-io/fyne/wiki/Proposal%3A-Aligned-and-Expandable-BoxLayout

in our other usage of the word Alignment it is to specify how something fits within the space.

Got it, then CrossAlignmentStretch could be private, just to add that default behavior to default constructors.

[fpabl0]

Closed in favor of wiki proposal.

[Naatan]

Hi, apologies for commenting on a closed ticket but how can I track the status of this proposal?

[andydotxyz]

https://github.com/fyne-io/fyne/wiki/Proposal:-Aligned-and-Expandable-BoxLayout

[Naatan]

@andydotxyz Should've been more clear; my issue isn't finding the proposal, it's understanding what is happening with it. Nothing about the proposal details its status or how someone might contribute to it.

[Bluebugs]

I know this is not necessarily answering your question, but have you looked at the responsive design experiment that was recently contributed to fyne-x? For a demo of it: https://github.com/fyne-io/fyne-x/blob/master/cmd/responsive_layout/main.go . It feels to me like it could maybe address the same need.

[Naatan]

I know this is not necessarily answering your question, but have you looked at the responsive design experiment that was recently contributed to fyne-x? For a demo of it: https://github.com/fyne-io/fyne-x/blob/master/cmd/responsive_layout/main.go . It feels to me like it could maybe address the same need.

Thank you! That definitely looks like it might address my use-case.

[andydotxyz]

@andydotxyz Should've been more clear; my issue isn't finding the proposal, it's understanding what is happening with it. Nothing about the proposal details its status or how someone might contribute to it.

There is an "Implementation" section at the bottom that lists any active work.
We have since moved proposals to a repository with pull request process so it is easier to see when they are approved.
The process of contributing is just the same as other code - PR or discuss in the community (see the contributing docs).