Skip to content

Add Drawing, Skia in GraphicsBackend.cs, to support other backend implementations#120

Closed
shonescript wants to merge 1 commit into
aprillz:mainfrom
shonescript:patch-1
Closed

Add Drawing, Skia in GraphicsBackend.cs, to support other backend implementations#120
shonescript wants to merge 1 commit into
aprillz:mainfrom
shonescript:patch-1

Conversation

@shonescript
Copy link
Copy Markdown

Hello,
MewUI is an excellent and great project. I believe it will become the best .net light crossplatform UI!👍
I try to to implement some backend implementations for portable or crossplatform purpose.
So I forked an MewUI project in https://github.com/shonescript/MewUI, and has one dependant on GraphicsBackend enum in the main project.
Is there a chance to extend it?🙂

Add Drawing, Skia to support some portable or crossplatform implementations
@lextm
Copy link
Copy Markdown

lextm commented Apr 19, 2026

Your ask is similar to #117 so you might join the discussion in #119 and #116 if you like.

Note that Drawing (if you meant System.Drawing) isn't cross platform. libgdiplus is not well maintained.

@shonescript
Copy link
Copy Markdown
Author

Your ask is similar to #117 so you might join the discussion in #119 and #116 if you like.
Ok, I'd like to. SkiaSharp is great corssplatform technique, especially for Android,IPhone,WebAssembly. I'll see the fork project Skia.MewUI.
Note that Drawing (if you meant System.Drawing) isn't cross platform. libgdiplus is not well maintained.
Yes, System.Drawing.Common is'nt, but third party such as Aspose.Drawing and Managed.System.Drawing can.
They share the same interfaces, many server side software use them to do in porcess drawing.
I have implemented them in the MewUI.Backend.Drawing project, using preprocessor-directives.

@al6uiz
Copy link
Copy Markdown
Member

al6uiz commented Apr 19, 2026

Thank you for the PR.

However, I cannot accept it in its current form.

I am currently working on contribution guidelines for the project, and the rough direction is as follows:

  • Small bug fixes: PRs can usually be opened directly.
  • Behavior changes: please start with an Issue or Discussion first.
  • New architecture, abstractions, or public APIs: these should have prior agreement before a PR is opened.

This PR is closer to the latter categories than to a small fix. Changes in this category should be discussed first before an implementation PR is opened. At this stage, I do not want changes that affect project direction to come in through an implementation-first approach.

For the time being, I will be prioritizing community foundations, such as a Code of Conduct and clearer PR/contribution guidelines, over adding new features.

Thank you again for the effort.

@al6uiz al6uiz closed this Apr 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants