[FileBrowser] Sorting by file modification time.

[TonCherAmi]

Hey, I'd like to add an option that would allow sorting files by modification time and I'm wondering how to best go about it:

• We could add a single option that only allows sorting by mtime (no atime or ctime):
  -file-browser-sorting-method [by-name|by-modification-time]
• Or we could do something similar to what ls does - there would be two options like:
  • -file-browser-sorting-method [by-name|by-time]
  • -file-browser-sorting-time [mtime|atime|ctime] (mtime being the default)

Personally I kind of like the second option better stylistically but at the same I'm not really sure whether it is going to be of any use to anyone and adding useless options should probably be avoided. What do you think?

[DaveDavenport]

i am not to sure on this one, (I prefer the 2nd), I could see this having added value (I would use it).

I also think we should not get to many options (working hard to reduce this), I had some plans to have something like this in config file to do more advanced tweaks:

file-browser {
   sorting: mtime;
}

But this is not worked out yet.

[TonCherAmi]

That's awesome, I've tried making these options a bit more structured and clearly defined so we don't have to perform a property lookup every time we need a config value. The draft is here. Please let me know what you think. If this looks like the way to go to you I'll go ahead and add documentation, migrate the existing options, etc.

[DaveDavenport]

I think that re-introduces some of the issues I hoped to solve by being more dynamic.

[TonCherAmi]

Hmm, could you elaborate a bit on what those issues are? I thought that the main problem was the excessive number of command line options, but I guess I misunderstood.

[DaveDavenport]

The -display-{mode} option is only available very late in the process (see related issue in 1.7 milestone), there is currently a 'hack' to resolve this in the config system.
By looking the option up dynamically this is no longer an issue.

[TonCherAmi]

Right, yeah, I see how this breaks options like that. What if we combine the two approaches though? First try and match properties against predefined XrmOptions, if they match remove them from the hash table, and at the end add all the remaining unmatched properties to rofi_configuration same as it is done now. That way we get the advantages of both predefined and dynamic options.