Not a bug, since the docs don't say one way or the other what style it returns.
However, I think the caller might want to choose.
My thinking is we could provide a flag that forces it one way or the other, and document that. Perhaps for backwards compatibility (where the style of paths in affects what is returned), it can be a three state flag, with the default being the current behavior, and the other two states being backs or fronts.
Trouble with that though is then ALL fltk functions dealing with paths should provide such an option, which might be bad/confusing.
So supplying a function that converts an input path to fronts or backs might be good. Though that's kind of trivial these days with the std::string stuff to just replace /'s with \\'s and vice versa.
In which case we could document the current behavior (possible mix of slash types), or force unix style. Not sure what the right call is in that case. Should probably choose one and document what it returns.
[ Direct Link to Message ]
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.