Architecture Q-GUI Specific Implementations Commonality

[tephyrnex]

I've been using OxyPlot.WindowsForms professionally for about 12 years. Recently, I'm interested in a personal project that would be cross platform; hence, I'm looking at OxyPlot.Avalonia.

First, I'm not that terribly familiar with the dev process in the projects involved; so, I could easily be missing something.

I've never looked into the class hierarchy and relationships between the separate GUI/Framework specific implementations before, but I'm a little confused why there isn't more derivation between the different implementations.

As a simple example, PngExporter in the WindowsForms and Avalonia implementations are 90% identical, yet are not derived from a common base class for code re-use. Instead, each is completely separate. This seems to require improvements and bug-fixes be duplicated across each GUI/Framework implementation.

I realize both implementations of PngExporter are derived from IExporter, but that only demands a common interface. It doesn't reduce duplicate code.

Am I missing something?

Be well, and thanks for everyone's hard work on a fabulous graphing/charting library.

[VisualMelon]

I suspect these sorts of discussions just haven't happened, because the history of the platform specific code-bases is so fragmented. Probably not very useful, but here's a rambly discussion anyway:

Re. PndExporter specifically, I don't think you're missing anything; I suspect this just hasn't really been considered. As I see it, there isn't all that much duplication of logic, because the types involved (i.e. bitmaps and render contexts) are all different

• Putting Width, Height, Resolution etc. into a super type would make sense
• The existing static methods (including bizarre extension methods) could be shared if we expand the API, unless they are removed altogether (breaking change) I don't think the situation will improve
• The fundamental Export and ExportToBitmap methods can't be simplified with code sharing (the Avalonia PngExporter is derived from the WPF one, but even there I don't think the duplication of logic can be reasonably be avoided)

Better consistency between exporters would be desirable, and I'm somewhat regretting removing the Background properties (in an effort to improve consistency #1978) from most of them (I note this never happened to OxyPlot.Avalonia), so if there are other aspects I may not be considering, I'd be interested to hear.

In general, the most duplication of actual logic is probably with the text layout code: #1556 is an old and ongoing (when I can find the time) effort to address (behavioural) inconsistencies between the providers. Otherwise, there isn't all that much I can see that could be reasonably pulled out of the WinForms implementation: basically every line of code is talking about some WinForms types, and is handling them in a way that e.g. isn't applicable to WPF.

The XAML stuff is a maintenance nightmare (hence why it's no longer maintained), but other than that, there isn't all that much platform specific code, and it doesn't change a lot, so I suspect the added complexity of trying to share code wouldn't be helpful in the end; but I could well be missing some components that would be good candidates for such a treatment.

[tephyrnex]

Understood. Thanks for the insight.
As a follow-up, I haven't found any documentation or guidelines for starting a port to a new GUI platform. Does such a thing exist?

[VisualMelon]

I'm not aware of any such documentation. I'm happy to try and provide pointers/answer questions here if you have something in mind, or on the OxyPlot gitter if the question doesn't seem worth opening an issue/discussion. Apart from the frameworks supported in the main repository and OxyPlot.Avaloina, I'll also call out the great work @HavenDV is doing, having adopted a number of abandoned provisions: https://github.com/HavenDV/H.OxyPlot ; I don't use any of them so can't really vouch for them, but his work is definitely where I'd start if I did need those platforms or similar ones.