Re-use of PresentationFramework

[jinek]

Do we have an option to re-write rendering of the PresentationFramework to re-use it in ConsoleFramework? Or may be it's possible to re-write some level of abstraction of it? For example, if it's not possible to re-write the rendering itself, may be it can be still possible to re-use FrameworkElement, or UIElement or at least DependencyObject? Or if it can not work with WPF, may be it could work with Xamarin, MIUI or any other XAML-based toolkits? More starting information on WPF drawing system: https://docs.microsoft.com/en-us/dotnet/desktop/wpf/graphics-multimedia/wpf-graphics-rendering-overview?view=netframeworkdesktop-4.8 WPF source-code: https://github.com/dotnet/wpf

The question itself is driven by idea to benefit from other things built for WPF, like virtualization, data binding etc.

I understand it's may be too hard to do the rendering of random visuals using ACSII table, still, may be it could be possible with some simplifications. As an example of such simplification I could think of rendering only some predefined elements, lets say ConsoleFramework.Border, ConsoleFramework.TextBlock etc.

To clarify, lets consider an example: 1) We include DevExpress components to our project 2) We define custom templates for needed controls:

<ControlTemplate Type="DevExpress:DxListBoxItem">
  <ConsoleFramework:Panel>
     <ConsoleFramework:Label Text="{TemplateBinding Content}"/>
  </ConsoleFramework:Panel>
</ControlTemplate>

3) ConsoleFramework does drawing only for predefined elements in UI tree and skips the rest. 4) Ofcoz our rendering can also skip other things, like Effects. All measurements, hit tests etc can be rounded to integer values

[jinek]

The answer is "yes, we have an option.

I've tried to tear down WPF, xamarin, MUIU and Avalonia. In short, Avalonia gives the possibility to build our console based rendering and windowing system. I've tried to implement very basic needed things: always one window - the console, drawing the text and the rectangle:

More detailed answer is: 1) WPF is strongly bound to win32 things, like loop, window handlers, directx drawing etc. 2) Xamarin abstraction is bound on the concept of native renderers, while we want layout, binding etc be providen by the framework 3) MUIU - similar to xamarin 4) Avalonia - has strong abstraction and implements all the things in portable manner.

Avalonia allows us to re-use its dependencyobject, bindings, layout, animation, styling etc

What we would need to make it working with avalonia is to implement windowing subsystem (we can have also an abstraction to work with regular console, Windows Terminal with many windows, etc), subsystem to show popups as a layer in our console and finally drawing subsystem, which must draw few basic primitives: text, line, reactangle, custom shape, it also must work with buffers to handle the case of intersecting the lines, shadowing and background pixel calculation.

I think this drawing system (based on avalonia) should be little more low-level than this ConsoleFramework, still it could have additions, which could emulate Windows, another one could re-use windowing of Windows Terminal etc.

As avalonia has it's own AXAML parser and related things, I don't think it would make sense to keep backward compatibility here, so the question is: Do we want to implement it as a new version of ConsoleFramework or do we want to have another one more project? This project already has about 500 stars and 50 forks which as I see could greatly help this new project.

@elw00d What is you opinion?

[elw00d]

Hi,

sorry for the late answer

What problem are you trying to solve ?

[jinek]

Hi,

sorry for the late answer

What problem are you trying to solve ?

I'd like to use data binding, virtualization, animation and other things provided by other frameworks. I think implementing that probably would require much more resources than re-using some existing code-base, like WPF or Avalonia

[elw00d]

IMHO using WPF seems not to be a great choice since WPF is not cross-platform and doesn't evolve forward, effectively frozen. What I know about Avalonia is that it is a rich UI framework, supporting many features and use-cases. I doubt that adding Avalonia as a dependency for this compact library will make it more simple to use. If you want, you can try to implement something like this anytime, but I think it will be quite hard to do.

[jinek]

I have tried to implement some. For now it's still just a proof of concept, but I believe it's already very close to first release: https://github.com/jinek/Consolonia I'm looking for maintainers, it requires several custom control templates, so please, consider supporting the project.