Skip to content

Add gio::Vfs subclass #1726

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

Merged
merged 2 commits into from
Jun 17, 2025
Merged

Add gio::Vfs subclass #1726

merged 2 commits into from
Jun 17, 2025

Conversation

fbrouille
Copy link
Contributor

Allow custom implementation of gio::Vfs

@fbrouille fbrouille force-pushed the gio_vfs_subclass branch 3 times, most recently from 2484ba8 to 8a65537 Compare May 23, 2025 20:02
@sdroege
Copy link
Member

sdroege commented May 25, 2025

Looks good to me except for the two open discussions about the string array.

@fbrouille fbrouille marked this pull request as draft May 28, 2025 18:45
@fbrouille fbrouille marked this pull request as ready for review May 29, 2025 15:24
/// It can be constructed safely from a `&StrV` and unsafely from a pointer to a C array.
/// This type is very similar to `[GStringPtr]`, but with one added constraint: the underlying C array must be `NULL`-terminated.
#[repr(transparent)]
pub struct CStrV {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name seems inconsistent with everything else. This is basically the String/PathBuf (StrV) vs. str/Path (CStrV) duality. Maybe this one should've actually been StrV and the other one StringV. Using Buf here seems wrong.

In other places (e.g. in gstreamer) there's a pattern of Foo and FooRef, so maybe we can just call this one StrVRef? @bilelmoussaoui what do you think?

Also GStringPtr is an ugly name, should probably reconsider that before the next release. Its difference with GStr is that it doesn't store the length and is equivalent with the raw C pointer. GStrLite or so... doesn't have to be solved as part of this PR but in case someone has ideas while we talk about naming anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CStrV because of std::ffi::CStr. However I agree that name should be consistent with others gtk-rs types. I think also that CStrV should be StrV and StrV should be StringV or if you don't want breaking changes, maybe renameCStrV to GStrV and rename StrV to GStringV and create a type alias (deprecated) StrV = GStringV.

Anyway let me know for CStrV new name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd still vote for StrV (stays as it is) and StrVRef. But waiting for @bilelmoussaoui to opine :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

StrvRef / Strv sounds good to me

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

This type represents a borrowed reference to a `NULL`-terminated array
of `NULL`-terminated UTF-8 strings.

Signed-off-by: fbrouille <[email protected]>
Signed-off-by: fbrouille <[email protected]>
@sdroege sdroege merged commit 611dc0d into gtk-rs:main Jun 17, 2025
48 checks passed
@fbrouille fbrouille deleted the gio_vfs_subclass branch June 17, 2025 09:57
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

Successfully merging this pull request may close these issues.

3 participants