You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IntoDrawingArea::into_drawing_area() has a return type that utilizes Self. This restricts into_drawing_area() from being used to only types that implement DrawingBackend. I propose using an associated type instead:
This definition would enable implementations on any type that contains or can create a DrawingBackend type.
(Optional) Why this feature is useful and how people would use the feature ?
When adding support for plotters in both Kludgine and Cushy, I realized I can't implement IntoDrawingArea for my types, because the types that implement DrawingBackend aren't the types exposed to the end-user for rendering. The reasons vary by crate:
In Cushy, I purposely hide direct access to the renderer type to provide a limited API surface. Even if 535 were changed, Cushy would still have to provide a passthrough DrawingBackend implementation instead of being able to implement IntoDrawingArea to provide compatibility.
The current workaround in both of my situations is to have my own crate-specific as_plot_area() functions that return a DrawingArea. I would prefer to replace these APIs with implementations of IntoDrawingArea.
The text was updated successfully, but these errors were encountered:
What is the feature ?
IntoDrawingArea::into_drawing_area()
has a return type that utilizesSelf
. This restrictsinto_drawing_area()
from being used to only types that implementDrawingBackend
. I propose using an associated type instead:This definition would enable implementations on any type that contains or can create a
DrawingBackend
type.(Optional) Why this feature is useful and how people would use the feature ?
When adding support for plotters in both Kludgine and Cushy, I realized I can't implement
IntoDrawingArea
for my types, because the types that implementDrawingBackend
aren't the types exposed to the end-user for rendering. The reasons vary by crate:estimate_text_size
to take&mut self
#535 required creating a wrapper that utilizes a RefCell. This wrapper type, not the renderer type, is what implementsDrawingBackend
.DrawingBackend
implementation instead of being able to implementIntoDrawingArea
to provide compatibility.The current workaround in both of my situations is to have my own crate-specific
as_plot_area()
functions that return aDrawingArea
. I would prefer to replace these APIs with implementations ofIntoDrawingArea
.The text was updated successfully, but these errors were encountered: