Improve the consistency of current presentation of paths to user.

[RokeJulianLockhart]

What's the Problem?

What https://github.com/files-community/Files/issues/9725#issue-1338304704:~:text=BEEDELLROKEJULIANLOCKHART%0A%20%20%0A%0A%20%20%20%20%0A%0A%20%20%20%20%0A%0A%20%20%20%20commented%0A%0A%0A%20%20%20%20%20%20now-,what's%20the%20problem%3F,-How%20paths%20are describes.

Solution/Idea

Consequently, similarly to what https://github.com/files-community/Files/issues/8465#issue-1147245420 proposes, I suggest that the format of presented paths be different. However, dissimilarly, my proposition affects all paths that this software presents/provides.

I propose:

1. https://github.com/files-community/Files/issues/8465#issue-1147245420

   Replacement of the backward-slash with the forward-slash when paths are presented to the user.

2. https://github.com/files-community/Files/issues/9725#issue-1338304704

   Prepend the necessary components to convert paths to file: Uniform Resource Identifiers to paths when presented to the user.

These suggestions have been combined because the 1st is partially dependent upon the 2nd.

Alternatives

What https://github.com/files-community/Files/issues/9725#issue-1338304704:~:text=by%20this%20format.-,alternatives,-Nothing%20alternative%20provides describes.

Priorities

What https://github.com/files-community/Files/issues/9725#issue-1338304704:~:text=provides%20similar%20consistency.-,priorities,-I%20do%20not describes.

Files Version

No response

Windows Version

No response

Comments

The forward-slash is represented by HyperText Markup Language code “&#47”, whereas the backward-slash is represented by HyperText Markup Language code “&#92”.

I utilize slash rather than solidus, because https://english.stackexchange.com/a/10996/343952 states that slash is correct for this purpose, despite https://english.stackexchange.com/questions/10993#comment18558_10996 correctly stating that Unicode incorrectly ignores this distinction. I apologize for any consequent confusion.

[Josh65-2201]

Merging with #8465

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1186227316

@Josh65-2201, https://github.com/files-community/Files/issues/8465 is definitely not identical to this. Please compare them: https://github.com/files-community/Files/issues/8465 barely suggests anything, and what it suggests is entirely different to what I have proposed.

[Josh65-2201]

Both requests suggest using the / instead of . You suggest other areas to use it whilst the other is just for the path. Both have the same end result so this to me is just additions. Plus the URI stuff is usally for browsers as they by default it searches content on the internet. I've never seen anything else use or have them as a requirement.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1186235909

@Josh65-2201, I do not suggest / instead of ., because . references the current path rather than separates it. (Did you mean \?)

Additionally, I do not understand how what you have stated negates the advantages of what I have recommended. If you truly appear to believe that my suggestion is without worth, please explain why.

[Josh65-2201]

Didnt mean . The back slash wasnt shown oddly. Its up to @yaichenbaum but i dont see it using URIs making sence. as for the / beeing use that diccused in the linked issue.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1186605844

Understood, @Josh65-2201. Thanks. However, I must say that I would be glad if this were added as a configurable option. Really glad.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1186605844

@Josh65-2201, I must mention that what this problem suggests and what you believe to be duplicate suggests are actually different things, too. https://github.com/files-community/Files/issues/8465#issue-1147245420 appears to suggest that paths be formatted as /c/Users/ rather than C:/Users, which appears nonsensical to me, because I do not know what would accept such weird and incorrect syntax for paths, whereas what I suggest conforms to all relevant standards, including enterprise UNC and URI paths!

Please reopen this or remove its designation as duplicate, because the problems that my proposition would remediate are utterly dissimilar to what that suggestion would supposedly remediate, and even if my suggestion for support for a URI appears nonsensical, my suggestion for modification of how paths are presented has not been previously proposed, especially by https://github.com/files-community/Files/issues/8465#issue-1147245420, and yet is standard practice within much .NET (and consequently PowerShell)-written software when achieving cross-platform support.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#event-7015978496

@Josh65-2201, thanks a lot.

[yaira2]

How paths are presented and managed by Files is inconsistent

What's this inconsistent with?

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1188438190

@yaira2, I phrased that badly by not specifying. I mean that it is inconsistent with most other operating-systems and cross-platform formats (all URIs that I know of, and definitely all URLs) despite Windows supporting this method of separation.

[yaira2]

That's an issue with Windows as a whole but I believe it makes sense to stay consistent with other applications on Windows.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1189319367

@yaira2, you shall be surprised by how much software internally uses forward-slashes (or abstracts the path if it uses .NET) for cross-platform support and consistency when manipulating paths (to concatenate them, primarily). Similarly to how it allows developers' lives to be easier, this allows technically inexperienced users to be less familiar with the different types of paths, especially because most are more familiar with URLs' paths, which solely use forward-slashes, even if hosted by Windows Server.

Consequently, I do not believe that what you state is ultimately assistive, because I doubt even that it is significantly more consistent.

[highfredo]

@Josh-65, I must mention that what this problem suggests and what you believe to be duplicate suggests are actually different things, too. "http://github.com/files-community/Files/issues/8465" appears to suggest that paths be formatted as “/c/Users/” rather than "C:/Users", which appears nonsensical to me, because I do not know what would accept such weird and incorrect syntax for paths, whereas what I suggest conforms to all relevant standards, including enterprise UNC and URI paths!

Please reopen this or remove its designation as duplicate, because the problems that my proposition would remediate are utterly dissimilar to what that suggestion would supposedly remediate, and even if my suggestion for support for a URI appears nonsensical, my suggestion for modification of how paths are presented has not been previously proposed, especially by "http://github.com/files-community/Files/issues/8465", and yet is standard practice within much .NET (and consequently PowerShell)-written software when achieving cross-platform support.

I proposed "/c/Users" because "C:" mounts to "/c/" in msys, but in testing I've seen that simply changing \ to / also works

By the way, cmd also supports /

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1192329956

Indeed, @highfredo: this is not specific to nor relevant to mysys, because what I have proposed is supported at the level of the NTFS filesystem (all but the low-level APIs). However, I am glad that what I propose would more consistently remediate https://github.com/files-community/Files/issues/8465#issue-1147245420.

Consequently, consider closing the previously mentioned issue if you are correct that this issue would remediate what you have stated.

[yaira2]

1stly, I suggest that solely the forward-slash be utilized to separate paths instead of the backward-slash.

This goes against the file system on Windows and unless something changes, we won't implement this suggestion.

2ndly, I propose that the “file://” Uniform Resource Identifier be prepended to the presented path if the path is not relative, because the URI allows more simple formatting of local and external resources than current native implementations provide, and are easily prepended to the paths that I have previously described. Additionally, paths that contain the URI are properly parsed by software that accepts them, despite solely utilizing the forward-slash, because the URI does not accept alternative path-separators, and are more easily understood by internet-browsers. "https://tools.ietf.org/id/draft-kerwin-file-scheme-07.html#unc-file-paths" appears to demonstrate that Windows's Universal Naming Convention paths are not problematic to convert, and certainly is superseded by this format.

This will come together with support for additional file systems (we're working on the foundation for this but it'll be a while before anything noticeable releases).

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1208887840

@yaira2, I very am glad that you have accepted my 2nd proposition! However, I am unable to comprehend what caused you to reject my 1st suggestion:

I suggest that solely the forward-slash be utilized to separate paths.

Are you able to explain your rationale more verbosely? I believe that I have previously explained how my suggestion does not oppose the current method of separation of paths except at very low API-levels, as "https://github.com/files-community/Files/issues/9570#issuecomment-1190945066" describes.

At the least, addition of it as an option would hurt absolutely nobody. It would merely require replacement of one character with another, after all.

[yaira2]

@BEEDELLROKEJULIANLOCKHART if we switched to forward slash, someone else will come along and ask that we switch to a backward slash. We made the decision to stay consistent with File Explorer and don't have plans to change this.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1213371990

@yaira2, is an option for this unacceptable? I understand now why you dislike it being the default. I believe that that is perfectly reasonable, but since I am a programmer that only uses one type of slash, to not have to constantly convert every path that I copy to my clipboard would be wonderfully useful.

[yaira2]

That's being tracked in #8465

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1213514741

@yaira2, it is not. I have absolutely no idea of what that issue describes. For instance, to replace C:\ with /c/ appears nonsensical to me, because of what I know, nothing supports that type of path-structure. The mentioned mysys2 might decide to create such a weird hierarchy within a virtual environment, if it creates one, but I don't know; I've never used it. Whatever it does, it does not describe what I suggest.

I don't even know why a file-manager would support something as niche as mysys2's directory-structure.

[yaira2]

Correct, if we support forward slashes it wouldn't be unix format, it would just be a forward slash. I edited that issue to reflect that.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1214263822

@yaira2, yeah, there isn't a UNIX format. UNIX uses a fundamentally incompatible virtualized hierarchy. Whichever symbol was chosen to separate paths is basically the same thing for both OSes anyway at any high-level, especially because most new software uses URIs to represent non-relative paths anyway.

I'll switch to discussing this issue at https://github.com/files-community/Files/issues/8465#issue-1147245420 because the title and description now don't reference /c/ and instead merely describe the type of slash.

However, are file URIs being tracked anywhere, since https://github.com/files-community/Files/issues/9570#issuecomment-1208887840 states that they are intended to be implemented? If not, I suggest that we create a new issue to track it rather than use this one to, because this issue suggests both things simultaneously.

[yaira2]

You can create a new issue for that but to be clear, I'm not committing to implementing it. What I can say is that the refactor will enable this if someone is willing to contribute it.

[RokeJulianLockhart]

https://github.com/files-community/Files/issues/9570#issuecomment-1214415689

@yaichenbaum, that is easy enough for me. I might be able to contribute it eventually.