Remove redundant file dialog string conversions #1665
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, there are a lot of redundant string conversions when using the file dialog api. This was mentioned briefly in #1622.
Here is a rough overview of the current situation:
Linux/macOS:
hxstring
->std::wstring
->std::string
, passed into tinyfiledialogs utf-8 api, thenstd::string
->std::wstring
->hxstring
hl_vstring
->std::wstring
->std::string
, passed into tinyfiledialogs utf-8 api, thenstd::string
->std::wstring
->utf-8
bytes -> nativeutf-16
hashlink string (on Haxe side viaString.fromUtf8()
)Windows:
hxstring
->std::wstring
, passed into tinyfiledialogs utf-16 api, thenstd::wstring
->hxstring
hl_vstring
->std::wstring
, passed into tinyfiledialogs utf-16 api, thenstd::wstring
->utf-8
bytes -> nativeutf-16
hashlink string (on Haxe side viaString.fromUtf8()
)This cleans things up to avoid unnecessary conversions, so now it looks like this in most cases:
Linux/macOS:
hxstring
->utf-8
[0], passed into tinyfiledialogs utf-8 api, thenutf-8
->hxstring
hl_vstring
->utf-8
, passed into tinyfiledialogs utf-8 api, thenutf-8
->utf-16
hashlink string (on Haxe side viaString.fromUtf8()
)Windows:
hxstring
->utf-16
[0], passed into tinyfiledialogs utf-16 api, thenutf-16
->hxstring
hl_vstring
, passed into tinyfiledialogs utf-16 api, thenutf-16
->utf8
->utf-16
hashlink string (on Haxe side viaString.fromUtf8()
)[0] hxcpp can use ASCII (which is compatible with utf-8) or utf-16 depending on the string, so these conversions are avoided in some cases.
We can improve Hashlink further (for Windows), by returning utf-16 strings from the apis, however, I'm not sure if this would be considered a breaking change (new lime.hdlls would be incompatible with old lime haxe files).
In #1622, we briefly discussed using the utf-8 tinyfiledialog functions on Windows to unify the api, however, I looked into this and on Windows these functions just convert back to utf-16, so there would still be extra conversions. So I think this is the cleanest solution.
I've tested on Linux and Windows with the code from #1622, and everything works well.