Consider unsealing the Render() of the Panel?

[liwuqingxin]

Is your feature request related to a problem? Please describe.

I would like to put separators between some ListBoxItem. Just like :
Item | Item | Item
So I want to extend the StackPanel and render some separators on it. It is the simplest way to do that, I think.

BUT, the Render() of Panel is sealed.

Describe the solution you'd like

Could you please unseal the Render() of the Panel. I can not come out why it is sealed, in my opinion.

Describe alternatives you've considered

No response

Additional context

No response

[AnnDevNet]

+1 !
I also need this like with wpf.

[pulsarware]

+1 me too

[timunie]

It is sealed because we may want to change how things work in the future and if it wasn't sealed, that may lead to conflicts and breaking changes.

Also I suggest to just add the sepator to ContainerItemTheme and if needed hide it for the last item. We have nth child selectors which could be useful here as well.

[leonidcan]

This already breaks code worked fine in avalonia 10, we have a project where we did our custom controls based of Image, TextBlock, Image, Panel. :(

[liwuqingxin]

@timunie Thank your for your reply!

Yes, I do this now. But it feels that putting the separator into the item container template is not lightweight enough. I should at least add a panel and a separator. In addition, I have to think about the layout of the separators in my mind so that they are accurately placed in the center of the two containers, which is troublesome to do. Even if I may need to place similar separators in different types of list controls, I need to modify the control template of each list container.

Unsealing the Panel's Render function will give the Panel more flexible extensibility, although it is optional.

If the user overrides the panel's Render function, then the user needs to be responsible for it. Render will only perform some additional auxiliary drawing and will not have an additional impact on the main function of the Panel-layout, which seems to be no breaking change. In contrast, allowing users to control measurement and layout arrangements seems to be more likely to cause conflicts and breaking changes, but this is inevitable, right?

[jp2masa]

Also I suggest to just add the sepator to ContainerItemTheme and if needed hide it for the last item. We have nth child selectors which could be useful here as well.

Unfortunately, it's not that simple, particularly for selectable items. The separator will visually appear as contained in the selectable/selected item, which does not make sense.

It still doesn't mean that overriding Render is required, as the separators can be created as visual children, which is logically the best option, in my opinion. It may also be possible to add one or multiple visual nodes to the compositor tree, but I would not recommend it.

To create the separators as visual children, it is as "simple" as overriding this method appropriately:

Avalonia/src/Avalonia.Controls/Panel.cs

Line 134 in 82e3613

protected virtual void ChildrenChanged(object? sender, NotifyCollectionChangedEventArgs e)

It's not very easy, but it should be maintainable and work well with virtualization if implemented correctly.

[liwuqingxin]

It may also be possible to add one or multiple visual nodes to the compositor tree, but I would not recommend it.

To create the separators as visual children, it is as "simple" as overriding this method appropriately:

Avalonia/src/Avalonia.Controls/Panel.cs
Line 134 in 82e3613
protected virtual void ChildrenChanged(object? sender, NotifyCollectionChangedEventArgs e)

That's right. This is a reasonable approach, if we only add separators to the list and do not do other operations such as iteratoring visual children.

Whether the separator is added in the control template or in the Children of the Panel, it is always a Visual in the visual tree. In some complex scenarios, we need to give them more attention.

What I mean is that we can use different ways to achieve this goal in different scenarios. Whether it is overriding the control template, overriding the Panel's ChildrenChanged, or overriding Render, these methods may be suitable for various scenarios.

If the Render method can be unsealed, the Panel will gain greater flexibility, even if this flexibility is not reflected in the scenario of adding separators, in some cases.

[Abidouz]

can this be simplify in any way

[BAndysc]

Agree, this change was unfortunate.

My ugly workaround is: https://github.com/BAndysc/WoWDatabaseEditor/blob/ad03280fc13e3544e46d0b1ace550973c72ef4f6/AvaloniaStyles/Controls/ControlRenderer.cs

Basically, it inserts an extra Control as the first child of the RenderedPanel, which is used as a "renderer" for the Render method.

[Coolkeke]

In fact, in normal development, we need to redraw complex lines and layouts for the ItemsPanel in ItemsControl. Now we need to re-render the Panel, but since the Rendering problem is sealed, we developers cannot perform advanced drawing and customization. Since developers have thought of using Rendering, they must bear the tedious processing problems brought by Rendering. I think there should be no Avalonia project members to control this problem, which has brought great inconvenience to developers. In order to solve the drawing problem, we have to redraw templates and recombine controls in large quantities to achieve the effect.
Our goal is actually to make great use of the API provided by the native Avalonia control to do some challenging functions, but because Rendering is sealed, we have to think of other ways to solve the inconvenience caused by this problem. In fact, it is necessary to open Rendering.
At present, my project needs to draw complex lines on the background of the Panel control, such as drawing grid lines for the Panel, and retaining some of the original functions of the Pane, which greatly increases the difficulty of our project development.
@timunie

[Mikolaytis]

With full respect to the team. I write this to guide someone who search the answers for these type of questions:

This is one of the decisions I fully disagree with. And no matter what I think and what they think sometimes you need a solution right now or tomorrow. Discussing this is waste of time and even if you will convince the team to make it public - a new version will launch no one knows when. In a week? can be a 3 months.

My approach is to make a full fork (it's closed source, sorry) and make public everything I need. When Avalonia makes an update all I need is to perform an easy auto-merge.
There is some challenges to make a fork with CI and your nuget alternative - it can take from day to week. I did it 4 years ago and up to today I think it was a good idea and the best solution.

[abirne]

If we intend to make Avalonia better and better, There is need to share our opinion and efforts in avalonia development. I think community feedback is a valuable thing which helps to improve Avalonia over and over.

[abirne]

We need to override the Panel.Render method for some porpuses:
Suppose we are creating a custom panel type and we must render some layouting guidelines (same as what is already done in avalonia Grid panel to show grid-lines). This is usefull for test and end usage porpuses, both.

With respect to the Avalonia Team and Thanks for their awesome works, It seems there is a Revolution of Internalizing of usefull things (or Sealing Overridable Methods) are occuring in newer avalonia releases.
This approach defects Avalonia adaptability and extensibility.
Obviously, various Development Teams and even Component Developers must be able to extend Avalonia world and develop controls and tools as well (Which leads to power avalonia more and more). Making APIs internal or sealing overridable things harms this.

If it is intended to replace an existing feature nextly with better one (which may lead to break changes), The true way is not to abandon the existing feature immediately (before the new one become) and harm the project's good atmosphere. As I know, there is some Attributes exists in Avalonia to warning developer, which maybe usefull in these situations.

Obviously, some projects need to customize existing controls including Panels and there is need to override the Render method as well. Actually There is Need For this.

With Best Regard.

@timunie

[rabbitism]

At some point we can just replicate code from Panel and unseal Render. But unfortunately, ItemsPanelTemplate only accepts Panel, which blocks the final last path toward panel rendering customization for real world use cases.
So now teams are

1. remove IPanel interface which blocks custom implementation of panel
2. sealed Panel.Render
3. Accepts only Panel for ItemsPanelTemplate.

I can accept that all sub classes of Panel have Render sealed, but Panel as the base class and the only accepted implementation of ItemsPanelTemplate, should not be sealed like this. @avaloniaui-team @MrJul