-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: move wgpu.gui into a new library #627
Comments
My proposal is: from rendercanvas.auto import RenderCanvas That name is free and pretty clear: it's a canvas to render to. Not wgpu-specific, actually, since anything that can render using either a window-id, or by providing an image, can use it. If you feel like bike-shedding on the name, I'm up for it 😄 I want to use the same select-by-import mechanics as before, and extend it a little bit: # Auto-select
from rendercanvas.auto import RenderCanvas
# Explicit lib
from rendercanvas.glfw import RenderCanvas
# Qt needs to know what lib to use
import PySide6
from rendercanvas.qt import RenderCanvas
# Let's also make this work
from rendercanvas.pyside6 import RenderCanvas
# If you have a renderer that only produces images
from rendercanvas.auto_image import RenderCanvas |
I added a quick summary in the top post to what this change means for downstream libraries. In short: no rush yet. |
I moved multiple issues, that related to the canvas, from wgpupy to the rendercanvas repo. |
TL;DR
wgpu.gui
into a new library calledrendercanvas
: https://github.com/pygfx/rendercanvaswgpu.gui
will remain working for a while, to ease transition.rendercanvas
.wgpu.gui
will be deprecated sometime after the "update propagation" changes in pygfx are all done. Nu rush.In earlier work the API for the canvas was separated better from wgpu itself. The idea was that in principal it should be considered a separate package. I now think we should really make it a separate package.
In short, the reason is that the canvas logic and API are about orthogonal to wgpu. It also solves a completely different problem. Things like tests and docs are also very different. Also, wgpu can be used without a canvas, and a canvas can potentially also be used without wgpu (it already supports displaying bitmap images).
With the rework that's on the way in #618 (and follow-up prs), I think now would be a really good time. We can apply all the new stuff (which will change the API a bit) to the new library, while we keep
wgpu.gui
as-is until we gradually deprecate it.The purpose of the new lib would be the same as our current
wgpu.gui
, but let's make it explicit:The text was updated successfully, but these errors were encountered: