xygine icon indicating copy to clipboard operation
xygine copied to clipboard

getRelativePath query

Open JonnyPtn opened this issue 7 years ago • 1 comments

I've noticed when using xy::Filesystem::getRelativePath() that the input has to be correctly formatted to get the expected results (unless my expectations are wrong... which I wouldn't rule out)

Say there's a file at /some/file/path/file.thing, I'd expect the relative path to the be the same when given these three "root" paths:

  1. /some/file/otherpath
  2. /some/file/otherpath/
  3. /some/file/otherpath/otherfile.thing

However 2 & 3 both return an extra directory higher (e.g. ../../path/file.thing instead of ../path/file.thing)

I could understand if 3 was left as it is, but I'd think 1 & 2 should return the same?

Slightly related to this - getFilePath() returns the directory path including the final /, so depending on your thoughts on this issue I'd maybe request to change that too, so it can be used as such: getRelativePath(somePath, getFilePath(rootFile))

JonnyPtn avatar Dec 29 '17 01:12 JonnyPtn

getRelativePath() was a legacy function used in the filebrowser window for ImGui - now deprecated by the NFD wrapper. It probably didn't get an actual relative file path, it's just a vague description of what it did in context - a context that is more or less deprecated. If you'd like to fix it up to behave more like you'd expect, then I'd be very grateful :) It'd also be nice to be able to remove the now useless ImGui file dialogue functions.

getFilePath() returns the final / because linux - although I'm guessing you're using macOS/unix so I uh.. dunno. Will have to contemplate that a bit. I think to my mind it was nice to have something like

getFilePath(file) + "someOtherFile.thing";

but right now it's hard to think of a use case

fallahn avatar Dec 29 '17 01:12 fallahn