Sorry @Ankur Deria (DAnkur), I wasn't clear in my previous comment.

What I intended to say, is that if the user types a string in all lowercase, then that intention should be preserved. So typing my preset should be displayed in the list as my preset.

The code that reads the filenames from disk and displays is in release/scripts/modules/bpy/path/py

Thank you for helping me and sorry if I am bothering you, I am a complete newbie to open source contribution.

No worries! We are all new at some point, and I'm happy to help.

The behavior is good now, but I think the implementation could be made a bit simpler and more flexible. Currently the function makes things title case unless it's an xml or py file. How about making display_name take an optional argument for title case that defaults to True. Then it wouldn't be dependent on file extensions, but on the caller deciding to use title case or not.

Then when draw_preset in bpy_types.py calls self.path_menu it can specify to use display name without title case.

Overall looks good now! There's a few small things now that you could change if you want, or I could make a few small tweaks before committing it for you.

Removed extra arguement in path_menu and passed in a lambda for display_name while calling path_menu from draw_preset.

Thank you for all the help :)

This patch seems fine.

Although, if we're changing how preset names are stored/displayed, we could move to URL quoting, see: urllib.parse.quote, urllib.parse.unquote.

Examples:

>>> urllib.parse.quote("My/Preset: High/Quality!", safe="")
'My%2FPreset%3A%20High%2FQuality%21'

>>> urllib.parse.unquote("My%2FPreset%3A%20High%2FQuality%21")
'My/Preset: High/Quality!'

This has the advantage of using a standardized way of storing characters that can't be written in path names, other (non-python) libraries support this too, so we could display them without Python - if that's ever needed.

Suggest to commit this to a branch, look into using URL quoting too. If this is a straightforward change, we could make this in one go. If it's more involved (for example, if existing presets cause errors loading)... this could be handled as a separate task - and this patch could go into master directly.

Also think URL quoting would be a good general solution to support unusual/reserved chars

@Brecht Van Lommel (brecht) I do have the fixes for bundled preset names in P1940.

I see two issues here. 1 is the incompatibility problems introduced by allowing full lowercase versions of the presets. 2 is support of special characters in the file names.

For the first, I think the simplest solution would be to commit @Ankur Deria (DAnkur)'s first version of this patch, which only removes saving user presets as lowercase, which wouldn't break compatibility with anything.

Then if we want URL encoding to support special characters in the names, that could be done later, but wouldn't be dependent on this patch.

If we want to fix both compatibility and avoid such quoting in filenames we could save the name inside the preset file somehow, like # Name: on the first line.

If Ankur's patch is committed in the simple form, then this could work as an alternative to URL encoding

@Ankit Meel (ankitm) thanks for catching that, it should be fixed now. rBA35d5df9bf4