Make the executable and symlink mime type colours configurable #235
Conversation
Add fixed symlink and executable categories to the mime-types dialog. They cannot be deleted from the dialog and will be recreated if they are deleted manually. Executables can also have patterns, symlinks can't. Crude, but simple. Modify the categorizer to handle symlinks and executables, and treemapView to call it.
Check if there are no categories before adding the Executable and Symlink categories, otherwise the defaults will never be added.
Keep pointers to the executable category and symlink category to avoid searching for them every time and save a few cycles. They are fairly common cases and this code already makes up a good proportion of the initial treemap paint, although mostly in the string handling a regular expression matches.
|
Edit: I thought I had commented it out, but obviously I undid that in the meantime. was that some legacy MS-DOS / Windows filesystem types (FAT, VFAT, NTFS) don't have a concept of execute permissions; they use the So when they are / were mounted on a Linux system, everything was implicitly executable, so all MIME categories that would otherwise be grey were purple (for executable files). I mount my NFTFS filesystems with mount options But how common is that really? How many users out there don't use those mount options for NTFS, or the more generic |
|
Should be, mostly, OK even for those cases. The purple only gets applied if no patterns match a file. So mostly they are files with no suffixes. If it becomes really annoying for some situation, the colour can now be configured to white. Or, patterns for *.exe, etc. can be added to that category. The default, white, colour for no match at all is still hard-coded. It could very easily be taken from a new value in the config file, but I'm not sure there is much need for it. The other bit is the symlinks. The comment in TreemapView was that the blue would get applied to directories, but that doesn't happen. Directories are only rendered with the plain colour or gradient, not cushion shading. That leaves only symlinks getting picked up as blue. I think this works. In the rare cases where a directory is empty or has only zero-length files, the grey gradient has a suitably "empty" appearance. There are a lot of symlinks, but mostly tiny and not very noticeable until they are zoomed in. |
|
Symlinks are sometimes stored directly in the directory file, if they are very short. In other cases, they consume one cluster (typically 4k) like other small files. In that case, and if it's a directory full of other very small files, and the treemap is very much zoomed in, they might become visible in the treemap. |
|
Certainly. Here's an example in an icon directory with a whole bunch of the tiny symlinks. Sometimes, they have an allocated size and show up bigger. |
Just retrieve a colour for the treemap instead of the category.
|
LGTM. Nice. Thank you! |
|
And please remember to rebase your master from the upstream master. You'll need to force-push your master then, of course. |
This code in treemapView was marked TO DO, so I did. There are now two extra categories:
The two categories cannot be deleted from the config dialog and will be recreated if they are lost from the config file. The colours can be configured. Patterns can be added for the executable category, but not for the symlink one.