Skip to content
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

Migrating to 1.0 #265

Open
ncfavier opened this issue May 7, 2024 · 6 comments
Open

Migrating to 1.0 #265

ncfavier opened this issue May 7, 2024 · 6 comments

Comments

@ncfavier
Copy link

ncfavier commented May 7, 2024

I'm trying to update rust-xcb-util to the latest version of xcb and running into issues figuring out the new API. For example, the xcb_window_t, xcb_atom_t etc. types used in the ffi modules are no longer exposed. What's the replacement?

@rtbo
Copy link
Collaborator

rtbo commented May 7, 2024

xcb_window_t and xcb_atom_t are replaced by the xcb::x::Window and xcb::x::Atom structs.

Both implement the Xid trait which provide the resource_id method.
resource_id gives you the underlying 32bits X identifier (aka xcb_window_t and xcb_atom_t)

@ncfavier
Copy link
Author

ncfavier commented May 8, 2024

Aha, I didn't expect it to be so simple as replacing xcb_window_t with xcb::x::Window.

Next question: what is the replacement for xcb::ReplyError::GenericError(xcb::GenericError { ptr: err }) (here)? The functions for resolving an xcb_generic_error_t to an xcb::Error do not seem to be exposed.

@rtbo
Copy link
Collaborator

rtbo commented May 9, 2024

Correct. I can make xcb::error::resolve_error public.
If the error is emitted by an extension, you need to pass the relevant ExtensionData, otherwise the function will panic. The ExtensionData array is also private.
I will create the relevant public functions to enable the error resolution for xcb-util.
Do you also need to resolve events ?

@ncfavier
Copy link
Author

ncfavier commented May 9, 2024

Do you also need to resolve events ?

No, I don't think so.

rtbo added a commit to rtbo/rust-xcb that referenced this issue May 9, 2024
 - `UnknownError` introduced and returned if resolution fails instead of panicking
 - Better consistency between error and event API

See rust-x-bindings#265
@ncfavier
Copy link
Author

ncfavier commented May 9, 2024

One more thing: after replacing xcb_get_property_cookie_t with xcb::x::GetPropertyCookie (and similarly for xcb_get_property_reply_t) in the above ffi module, I get warnings like the following:

warning: `extern` block uses type `xcb::x::GetPropertyReply`, which is not FFI-safe
   --> src/ffi/icccm.rs:202:54
    |
202 |     pub fn xcb_icccm_get_wm_protocols_from_reply(reply: *mut xcb::x::GetPropertyReply, protocols: *mut xcb_icccm_get_wm_protocols_reply_t) -> u8;
    |                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
    |
    = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
    = note: this struct has unspecified layout

Should these types all be marked repr(C)?

@rtbo
Copy link
Collaborator

rtbo commented May 10, 2024

No. xcb::x::GetPropertyReply is a struct containing a pointer to the FFI struct.
What you want is to get the inner pointer.
You can get it with current API through xcb::Reply::into_raw, but this will consume the reply, leaving you in charge to free the pointer.
I will add xcb::Reply::as_raw, which is more appropriate for your need.

rtbo added a commit to rtbo/rust-xcb that referenced this issue May 10, 2024
@rtbo rtbo mentioned this issue May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants