Use Rust modules to replace namespace prefixes

[tadeokondrak]

With the current API, to use the wl_data_device_manager object, you have to import protocol::wl_data_device_manager::WlDataDeviceManager.

If it were to be put in a wl module rather than a protocol module, some redundant parts could be removed: wl::data_device_manager::DataDeviceManager.

Since it's the main item in the module, it could be re-exported in the parent module (similar to std::collections), so you'd only need wl::DataDeviceManager.

Event/Request/other enums could stay in the module, accessed like wl::data_device_manager::Event.

Currently, request/event since-versions are module-level constants, like wl_data_device_manager::REQ_CREATE_DATA_SOURCE_SINCE. With associated constants, that can be wl_data_device_manager::Request::CREATE_DATA_SOURCE_SINCE. This is separate from the namespace change, but can be done if it's being changed anyway.

This doesn't only work with prefixes, this can be used for unstable versions too, so wayland_protocols::wlr::unstable::layer_shell::v1::client::zwlr_layer_shell_v1::ZwlrLayerShellV1 can become something like wayland_protocols::client::zwlr::v1::layer_shell::LayerShell. But I'm not sure about this one, since multiple v1 protocols from the same namespace aren't really related by that alone.

The prefix/suffix for each protocol would have to be annotated for wayland-scanner, which would only remove them, and the module organization could be done manually.

[elinorbgr]

The reorganization within protocols to flatten them sounds good overall, but I think we should keep each protocol of wayland-protocols into its own module, to keep some clarity of what goes with what mostly.

So, maybe an organization like:

wayland-protocols::{
    xdg::{
        shell::{
            /* contents of the xdg-shell protocol */
        },
        decoration::{
            // unstable protocols have version submodules, stable protocols do not
            v1:: { /* ... */ }
        },
    ...
    },
    wp::{
        viewporter::{ /* ... */ },
        presentation_time::{ /* ... */ },
    },
    wlr::{
        /* ... */
    }
}

I'm not really sure where the client/server distinction should go tbh: at the crate level, before the namespaces, or within each protocol module?

[tadeokondrak]

That makes sense.

I'm not really sure where the client/server distinction should go tbh: at the crate level, before the namespaces, or within each protocol module?

I think it would work best at the crate level, since it's rare that you need both in the same scope.

[WhyNotHugo]

I'm not really sure where the client/server distinction should go tbh: at the crate level, before the namespaces, or within each protocol module?

Why is this distinction needed? The types on both seem to be the same, e.g.:

wayland_protocols::wlr::unstable::data_control::v1::server::zwlr_data_control_offer_v1

wayland_protocols::wlr::unstable::data_control::v1::client::zwlr_data_control_offer_v1

I can't find any that actually differ; can't the same types be used for clients and servers?

[tadeokondrak]

I can't find any that actually differ

The first struct has a different representation and set of methods.

[WhyNotHugo]

You're right. And including all of them in a same struct would result in really bad developer experience.