New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path to files and folder in lowercase #252

Closed
alexandr-san4ez opened this Issue Oct 24, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@alexandr-san4ez

alexandr-san4ez commented Oct 24, 2017

I noticed that in version 2.16.2 all paths to files or folders are in lowercase. No matter what actually.
In version 2.15.4, this does not happen.

Is this a mistake or is it done intentionally?
Personally, I would like to return the normal paths as it was before.

I checked this on the plugin - FileBrowser.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Oct 24, 2017

Member

This is intentional and is meant to remain that way. Heavy work has been done under-the-hood for v2.16 to ensure the paths of FILE items are normalized so they can be compared as safely as possible between two running sessions. How would that be an issue for you?

Member

polyvertex commented Oct 24, 2017

This is intentional and is meant to remain that way. Heavy work has been done under-the-hood for v2.16 to ensure the paths of FILE items are normalized so they can be compared as safely as possible between two running sessions. How would that be an issue for you?

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Oct 24, 2017

Member

Also, note that this impacts only the target property of the FILE items. Not their display name.

Member

polyvertex commented Oct 24, 2017

Also, note that this impacts only the target property of the FILE items. Not their display name.

@alexandr-san4ez

This comment has been minimized.

Show comment
Hide comment
@alexandr-san4ez

alexandr-san4ez Oct 24, 2017

Thanks for the answer. This is not a big problem so I will survive it. :) It's just a habit to get the right ways.

alexandr-san4ez commented Oct 24, 2017

Thanks for the answer. This is not a big problem so I will survive it. :) It's just a habit to get the right ways.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Oct 24, 2017

Member

Normalized paths is the right way :)

Member

polyvertex commented Oct 24, 2017

Normalized paths is the right way :)

@laurin1

This comment has been minimized.

Show comment
Hide comment
@laurin1

laurin1 Oct 24, 2017

Well, I'm not sure I agree with that, but I could live with if it was only search results, but it's actually someone changing some of my application titles??

Launching from KP:
image

Launching by any other method:
image

laurin1 commented Oct 24, 2017

Well, I'm not sure I agree with that, but I could live with if it was only search results, but it's actually someone changing some of my application titles??

Launching from KP:
image

Launching by any other method:
image

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Oct 25, 2017

Member

Funny. Weird. Definitely not KP-related [1] but obviously an inconvenient issue.

To circumvent that, KP can keep fully normalizing the root part of the path (i.e. drive part or UNC prefix) and just canonicalize the tail of the path without changing its case/casing. But this comes with the cost of being more CPU demanding when inserting items into KP's catalog because full normalization is required at some point to compare items. Although my guess is that it will be hardly noticeable at user-level so it is an acceptable solution.

[1]: the display name of an application/control panel is not meant to change just because you invoke it with a different character casing, unless the said application relies too much on user input (that would be the issue)

Member

polyvertex commented Oct 25, 2017

Funny. Weird. Definitely not KP-related [1] but obviously an inconvenient issue.

To circumvent that, KP can keep fully normalizing the root part of the path (i.e. drive part or UNC prefix) and just canonicalize the tail of the path without changing its case/casing. But this comes with the cost of being more CPU demanding when inserting items into KP's catalog because full normalization is required at some point to compare items. Although my guess is that it will be hardly noticeable at user-level so it is an acceptable solution.

[1]: the display name of an application/control panel is not meant to change just because you invoke it with a different character casing, unless the said application relies too much on user input (that would be the issue)

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Oct 26, 2017

Member

Aforementioned behavior implemented in v2.16.3

Member

polyvertex commented Oct 26, 2017

Aforementioned behavior implemented in v2.16.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment