Grid with named columns and rows

[fhaag]

I see that Avalonia's Grid control offers a simplified way to define columns and rows compared to WPF's, where each ColumnDefinition/RowDefinition had to be listed as a separate Xml element. So far, so good.

One thing I have always been missing from WPF's Grid control was, however, that its column and row referencing is based on indexes. In practice, I have always found this quite cumbersome:

• Insert a column or row later on and you have to update all the indexes of all the existing controls right of/below the newly inserted column/row.
• Split a (w.l.o.g.) column mid-way, so some controls occupy the full width of the previous column while in other rows, two controls are now side-by-side? Same thing.
• Especially during such changes, it's easy to have controls accidentally end up a column or row beside where they ought to be, but hard to see in code.
• If you wish to insert spacer columns (basically, pure cosmetics), you better do so from the start.

On top of that, the fact that ColumnDefinition and RowDefinition are named differently (not nice for copy-and-pasting if you want to "transpose the matrix") is unfortunate.

---

That's why, many years ago, I created a WPF control called NameBasedGrid (Github; Nuget), which has served me well in plenty of projects:

• It replaces ColumnDefinition and RowDefinition with a ColumnOrRow element (though if there is an English word that really is a general term for columns and rows, I'd be happy to hear it).
• It allows for naming these column/row definitions, and controls in the grid can be aligned based on the column/row names.
• It supports virtual columns/rows that are basically names for ranges of 1..N columns/rows.

Please have a look at one of the sample files for an overall impression.

---

Even though the above control used to fulfil my needs, time and again I wondered why I need an extra Nuget package (and extra namespaces in my Xaml), as that functionality seemed such an obvious omission in the original WPF grid to me.

With Avalonia, here's where I see a chance: Do the people behind Avalonia, in particular the Grid control, think the column/row naming capability would be a worthwhile extension to Avalonia's standard Grid?

If so, I would like to help.

[thevortexcloud]

I personally think having to manually define rows/columns is extremely tedious. Avalonia used to have a control called AutoGrid, which would automatically do it all for you. It is however now extremely out of date.

https://github.com/AvaloniaUI/AvaloniaAutoGrid

I don't personally see the point in naming them though. I almost never reference a grid from code behind, and even when I do; I typically only care about the grid itself. In most cases I just want the grid to display stuff without much ceremony. I don't think I have ever had a dynamic grid either. I typically just use a datagrid at that point.

[fhaag]

Note that column/row naming is not about referencing anything from code-behind. It's about placing your controls in the grid by stating "This control goes into the Name row and the Inputs column" rather than "This control goes into row 8 and column 3."

As for the AutoGrid, I'm not sure how that behaves when your grid has to contain lots of "irregular" things (skipped cells, some controls spanning several columns, etc.).

Also, I'm thinking of a grid used to layout the contents of e.g. a dialog box. Not anything like a data grid that looks and feels like a dynamic grid control to the user.

[LaurentInSeattle]

I see a lot of value in this idea. I have spent way too much time renumbering Grid.Row's or Grid.Column's properties !

However, I think this should be implemented as a XAML extension for the regular grid, and not by creating a specialized derived control.

[fhaag]

Absolutely, I could imagine the shorthand form of the column (or analogously, row) definitions could be written something like ColumnDefinitions="*, MyColumn=*, MyOtherColumn=250", to optionally allow names right in there. Virtual columns/rows might have to be declared in a separate list.

I will investigate whether I can find out how that could be achieved.

[fhaag]

These are the changes I would like to introduce - note that all of these are additions to the existing Grid class and associated types; the existing index-based properties can still be used exactly the same way:

---

Part 1: Support specifying columns/rows by keys rather than indexes:

The goal here is to decouple the column and row assignment from the physical layout. Rather than referring to columns and rows by their index (which is zero-based from left/top and changes every time a column or row in front is inserted or removed), refer to them by a key. Unlike an integer index, this key can be chosen to be a self-explanatory text. Furthermore, counting of spanned columns/rows is not necessary; you just specify the columns/rows to definitely span, and anything in between will be included automatically.

• On DefinitionBase, add a Key: string property.
  I suggest these are limited to ^[A-Za-z][A-Za-z0-9]*$, with "AUTO" being a reserved term.
• Modify ColumnDefinitions::ctor(string) and RowDefinitions::ctor(string) so they no longer rely on GridLength.ParseLengths. Instead, have them use a new method that parses a comma-separated list of entries, which may have any of the following forms:
  • A string representing a GridLength (i.e. a double value, a double value suffixed with "*", or the text "AUTO") results in a column/row of the specified size as before.
  • A string matching the above key pattern results in a column/row with the default size value and its Key initialized to the specified text.
  • A string matching the form <key pattern>=<grid length> results in a a column/row with both Key and size initialized.
• On Grid, add the attached properties ColumnKeys and RowKeys.
  Open question: Should these be of type string[], or of some IList<string>-compatible type that also allows for easy deserialization from a comma-separated string? Or just the comma-separated string, which is then split up only when required?
  Setting either of these properties will cause the indexes for all listed columns or rows to the retrieved. Then, the Column/Row and ColumnSpan/RowSpan properties will be set so the control spans all of the listed columns/rows.

---

Part 2: Support virtual columns/rows:

This addition allows to define key aliases for columns/rows (or even ranges thereof). This simplifies the process of assigning the same column/row span to multiple controls.

• Add a VirtualColumnOrRow class with the properties Key: string and IncludedKeys (same type as ColumnKeys and RowKeys above).
• On Grid, add two properties VirtualColumns and VirtualRows, both of a type compatible with IList<VirtualColumnOrRow>.
• Modify the processing of ColumnKeys and RowKeys to consider the virtual columns and rows, respectively. If the key of a virtual column or row is encountered, it gets replaced with the values from its IncludedKeys property.
  A virtual column or row can only include keys of actual columns or rows. This should suffice in most cases and prevents the possibility of cyclical definitions.

---

Would a PR to this extent have a chance of getting accepted? How do I find out whether the Avalonia core team are in favour of this extension?

[MarkusKgit]

I like this proposal a lot 👍

[Poker-sang]

Resolving the vexing renumbering issue is certainly worthwhile, but I don't believe it's necessary to introduce a new naming convention (which offers little benefit and constitutes a new API).

Instead, adding a XAML Code Fixer can achieve the same result: simply add “Insert row/column before/after” within the Row/ColumnDefinition context, then let the Code Fixer handle the renumbering. This approach is straightforward and avoids introducing any new changes.

[LaurentInSeattle]

I did a bit of googling and could not find anything relevant about such a Code Fixer tool. Any pointers? Thanks !

[Poker-sang]

I'm not sure, maybe roslyn cannot help. But Resharper, Rider, and Avalonia all provide syntax highlighting and context menus for AXAML. So I think this might be possible too. (Maybe through vs extension?)

[fhaag]

Instead, adding a XAML Code Fixer can achieve the same result

I beg to disagree here:

• The code fixer does nothing to help with the fact that you see just some cryptic numbers rather than descriptive column/row names in XAML.
• Also, the code fixer solution does not address the possibility of using aliases for columns/rows, or even spans thereof.

Indeed, the API would be changed ... YMMV on whether it's a better choice to require an extra IDE tool so a cumbersome API can be handled, or to actually make the API itself more usable.

[Poker-sang]

Admittedly, Code Fixer cannot resolve readability issues, but the most challenging column renumbering problem has been addressed—and even improved upon. Consider the following scenario:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Name="First" />
+       <ColumnDefinition />
        <ColumnDefinition />
    </Grid.ColumnDefinitions>

    <Button Grid.Column="First" Grid.ColumnSpan="2" />
</Grid>

When adding a second column, Button.ColumnSpan should be set to 3, but the named grid cannot handle this automatically.

But Code Fixer can refactor based on the Column and ColumnSpan of each child control (When you insert a column, Code Fixer will automatically adjust the ColumnProperty of subsequent columns. And modify the ColumnSpanProperty as described above.).

[fhaag]

When adding a second column, Button.ColumnSpan should be set to 3, but the named grid cannot handle this automatically.

Yes, it can. Based on the interface I outlined above, it would be written like this - because ColumnKeys / RowKeys has a semantic of "span all the listed columns/rows, and anything in between":

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Key="First" />
+       <ColumnDefinition />
        <ColumnDefinition Key="Second" />
    </Grid.ColumnDefinitions>

    <Button Grid.ColumnKeys="First,Second" />
</Grid>

Using aliases, it can become even more descriptive:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Key="First" />
+       <ColumnDefinition />
        <ColumnDefinition Key="Second" />
    </Grid.ColumnDefinitions>
    <Grid.VirtualColumnDefinitions>
        <VirtualColumnOrRow Key="FullWidth" IncludedKeys="First,Second" />
    </Grid.VirtualColumnDefinitions>

    <Button Grid.ColumnKeys="FullWidth" />
</Grid>

Note how this also works with other layouting changes, such as swapping the columns:

<Grid>
    <Grid.ColumnDefinitions>
-        <ColumnDefinition Key="First" />
        <ColumnDefinition Key="Second" />
+        <ColumnDefinition Key="First" />
    </Grid.ColumnDefinitions>
    <Grid.VirtualColumnDefinitions>
        <VirtualColumnOrRow Key="FullWidth" IncludedKeys="First,Second" />
    </Grid.VirtualColumnDefinitions>

    <Button Grid.ColumnKeys="FullWidth" />
</Grid>

But Code Fixer can refactor based on the Column and ColumnSpan of each child control (When you insert a column, Code Fixer will automatically adjust the ColumnProperty of subsequent columns. And modify the ColumnSpanProperty as described above.).

Consider what the (Git or otherwise) diff of such a change will look like. Compared to the diffs above.