This is a tracking issue for adding support for the canvas 2D API to the web-sys crate.
General info on canvas 2D: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API
How to add support for new Web APIs to web-sys: https://rustwasm.github.io/wasm-bindgen/web-sys/supporting-more-web-apis.html
Here is a list of interfaces we need to support:
examples/ that shows off working with canvas 2DI鈥檇 like to pick this up! 馃槉
Is there a story for handling mutliple constructor functions? Right now doing a cargo build on CanvasRenderingContext2D.webidl errors with
the name `__wbindgen_describe___widl_f_new_Path2D` is defined multiple times
which makes sense based on the idl
@teovoinea for now that I don't think is supported so it should be fine to comment out one or two of the constructors, but in the long run we'll want to probably add support to generate multiple differently named constructors for instances like that
What do you think, which names in Rust should be used for constructors/functions with same names, but different argument types? Should they be generated from types names? Or manually annotated somewhere?
The current thinking is that we'd do something programmatic like:
newfoo is named new_with_foofoo and bar is named new_with_foo_and_barAnd at least see how far that gets us, although we're also ok commenting out the duplicate constructors for now!
The problem is that for WebSockets all 4 overloads of method send are useful, and they have same argument names:
[Throws]
void send(DOMString data);
[Throws]
void send(Blob data);
[Throws]
void send(ArrayBuffer data);
[Throws]
void send(ArrayBufferView data);
Aha yes! For that we may want to just special case/edit the WebIDL perhaps? Or maybe we can include the type name in the method name? (aka send_dom_string(data), etc)
Yes, and that is exactly what I am asking. Are current WebIDL entirely taken from somewhere else? Edits to them may make updating process harder. In case of generated names, it would probably require doing so in such way that every type has a distinct name (not sure if it will cause any problems).
The WebIDL is taken from Gecko's source tree I believe. There's no current consensus on how to solve this issue. Ideally it'll be handled in the webidl crate with the code it generates, and editing the WebIDL itself would be a last resort, yes.
I am currently working on a prototype of an implementation of automatically generated names.