For InNewWindow<T> struct fields, the corresponding WindowAttributes declare an inner_attributes value that can be set to the attributes of T. However, there is no example for doing this when deriving Inspectable through the proc-macro (#[derive(Inspectable)]) which is an issue because it doesn't follow the conventional syntax.
Typically (c.f. popular crates like serde), when #[foo] attributes support nested values, they do so using a function-like syntax, e.g.:
Unfortunately, that's not supported. I did some digging into the proc-macro code for the attribute and found that the way to make it work is to explicitly create the value for inner_attributes and assign to it:
For
InNewWindow<T>
struct fields, the correspondingWindowAttributes
declare aninner_attributes
value that can be set to the attributes ofT
. However, there is no example for doing this when derivingInspectable
through the proc-macro (#[derive(Inspectable)]
) which is an issue because it doesn't follow the conventional syntax.Typically (c.f. popular crates like serde), when
#[foo]
attributes support nested values, they do so using a function-like syntax, e.g.:One would expect
#[inspectable]
to do likewise:Unfortunately, that's not supported. I did some digging into the proc-macro code for the attribute and found that the way to make it work is to explicitly create the value for
inner_attributes
and assign to it:This is quite unusual; normally, users don't have to explicitly provide values of the crate's own types when using a
#[derive]
macro.I'd suggest providing an example of this atypical use of
inner_attributes
. or changing it to follow de-facto conventions of the Rust ecosystem.