Support true Linux file paths

[MookThompson]

Hi magiblot,

I'm using some of the common dialogs on Linux (change directory in particular), and it's rather confusing to a Linux user that Linux file paths are all translated to DOS-style paths (eg '/home/mat' is shown as 'C:\home\mat'). This is particularly so on WSL, as 'C:' is a valid Windows drive, so it looks like you're navigating the Windows FS rather than the WSL Linux one.

Also, if you do try to initialise TDirListBox to a Linux-style path using eg newDirectory("/home/mat"), you get a segfault due to these lines in TDirListBox::showDirs():

end = strrchr( dir, '\\' ); 
...
strncpy( path, dir, size_t(end-dir+1) );

as end is NULL when a Linux-style path is specified. (My crude fix is just "if (end==NULL) return;", which seems to work fine in my use-case as I don't try to treat the path as valid).

I've worked around it myself by copying and hacking TChDirDialog and TDirListBox to support Linux-style paths natively on Linux, but it looks like the whole 'simulate DOS paths on Linux' is a bit more ingrained in the tvision port? In particular, whilst on Windows both '\' and '/' are invalid characters in paths (so can both be treated as path separators), on Linux '\' is a valid path character. Properly supporting native Linux paths would probably mean you would lose the ability to translate Windows-style paths automatically, which may have implications for the tests etc?

If you're interested, I can provide a PR with the changes I needed to fix the crash and make TChDirDialog behave natively on Linux so you can see what I needed to do for reference. I've done this using the _TV_UNIX #define, rather than a runtime flag, as I don't need to support Windows-style paths on Linux.

[magiblot]

Hi @MookThompson!

When I began porting Turbo Vision, I quickly figured out that the filesystem-related views were a pain in the neck since they were totally incompatible with Unix paths. I then tried to re-implement them using std::filesystem and #ifdefs, but that turned out to be even more painful. So yes, I eventually came up with this "simulate DOS paths on Linux" strategy, which allows the original filesystem-related views to work without major changes, but at the cost of not supporting paths containing '\' on Unix nor paths longer than ~255 characters. So it can be said that the implementation of these views is broken, even though it works for most cases.

However, I didn't mind much about this because I also thought that a good UX would require writing new dialogs from the ground up (e.g. combining a file list and a directory tree, with an option to show hidden files, etc.). But in the end I didn't write such dialogs.

Anyway, it is certainly not good that TChDirDialog shows Windows-style paths on Linux, considering that TFileDialog already does not, and it should of course not crash. I would indeed be very grateful if you could share your changes.

Cheers.