Conversation
`path_init` is solely used by / useful for the `xplm_init` function so I don't expect this will cause any difficulties
As std::path::PathBuf rather than string Only tested on Windows - hopefully works seamlessly with other platforms due to `XPLM_USE_NATIVE_PATHS` feature? I've appropriated the `paths` module for them Fixes mkreu#25
|
I should mention, I've tested this on Windows only, but would hope it works seamlessly on other platforms! Fixes #25 |
mkreu
left a comment
There was a problem hiding this comment.
Thanks for the contribution! Looks good to me, just have to minor comments
I will test it on linux and I guess we just hope it works on mac as well :D
| } | ||
|
|
||
| /// Enables native paths | ||
| pub fn path_init() { |
There was a problem hiding this comment.
| pub fn path_init() { | |
| fn path_init() { |
Unless I am missing something, there should be no reason anymore for this to be public
| /// X-Plane and plugin paths | ||
| pub mod paths; |
There was a problem hiding this comment.
We should add docs to the path module that we always return native paths because we turn on the resprective feature during xplm_init.
There was a problem hiding this comment.
Sorry, I missed this... these functions return PathBuf objects from the Rust standard library - isn't that platform-agnostic? I thought the "native paths" feature was a convenience for C programmers!
This provides four new functions:
They return
PathBufobjects, which the user will presumably find straightforward to navigate from to get, e.g., the aircraft root folder.I've moved the
path_initfunction to theinternalmodule and promotedpathsto pub mod - is that OK?