Open loathingKernel opened 6 years ago
Thanks for your first steps into this direction. It's needed in order to address #101, #159 and #162 and it would obviate the need for #166.
I have an issue with large icons (96 and 128 I believe) when using custom colors. If someone more knowledgeable of the theme could take a look at what is possibly missing, it would be greatly appreciated.
Edit: It seems to be unrelated to this PR as the file lists generated in both cases are identical.
Why use ~/.icons
as the destination dir as opposed to the more xdg-ish ~/.local/share/icons
? Is ~/.icons
more compatible or something?
There wasn't any specific reason I chose ~/.icons
over the xdg equivalent, just force of habit.
Bug which arises with this method is that any symlinks not included in the created "Numix Folders" theme aren't being picked up by the inheritance system. Not sure why that's the case but further testing there needed also.
The bottleneck is the amount of symlinks and that find
is invoked all the time. That combined with that fact that it is doing string manipulation in bash (which is still faster than invoking external programs) makes up most of the execution time. I don't think that the current solution as it is can do any better, it will require a change of method, possibly a rewrite. If so, I would suggest to move it to Python or something similar for better code clarity and possibly performance.
The issue with the custom folder colours not being used in large sized icons is due to those icons being symlinked from the system-wide Numix folder as they don't exist in the Numix-Folders. A solution could be to copy those files, either in the script or by including them in Numix-Folders.
A solution could also be to just copy everything to the local folder on top of each other and be done with it. I will also be faster, but the script should be run then on every update and more storage space will be required.
On a second look, there are a few more tricks that can be done to fix all of these.
When Numix Folders application is run as a regular user, and the themes are installed system-wide, instead of replacing files in system-wide, create a new theme which inherits the base theme specified by the user. This helps with package managers that expect for files installed in
/usr
to remain untouched. Also helps with package upgrades of the base themes.Although it works, I haven't tested it thoroughly yet, so I consider it work-in-progress. It is quite slow for now, possibly because most string manip is done in bash or inefficiently. Still, I would like to get some more eyes on it.