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
There are some issues that could be fixed by modifying the XML definitions. For example #156 could be fixed by adding name= attributes and #357 could be fixed by fixing and uncommenting the broken definitions. Additionally, some unions could be converted into switches to make the API more rust-y.
However, many of those modifications cannot be merged upstream because they would likely break libxcb. So, it might be a good idea to think about a way of patching our copy of xcb-proto with x11rb-specific changes.
The text was updated successfully, but these errors were encountered:
For now, I'd prefer to merge changes upstream. In theory, I have commits right there, but in practice, I never really touched xcb-proto and only did some things on libxcb. Thus, I would not really want to "just merge" something there.
Anyway, the name= you propose for #156 could just be added there. Uncommenting the broken definitions for #357 could be merged upstream together with an extra patch to libxcb that makes it ignore the new stuff in there.
I am not really sure about converting unions to switches. For xproto's ClientMessageData... oh, that's actually possible. Same for the <union> in randr. Hm, nice idea.
There are some issues that could be fixed by modifying the XML definitions. For example #156 could be fixed by adding
name=
attributes and #357 could be fixed by fixing and uncommenting the broken definitions. Additionally, some unions could be converted into switches to make the API more rust-y.However, many of those modifications cannot be merged upstream because they would likely break libxcb. So, it might be a good idea to think about a way of patching our copy of xcb-proto with x11rb-specific changes.
The text was updated successfully, but these errors were encountered: