Try to load color themes from system-wide location

[danfe]

Currently, CliFM attempts to load color schemes from the COLORS_DIR, which resolves to $(HOME)/.config/clifm/colors. This is correct location to store user-modified data, but typically, system-wide directories (e.g., /usr/local/share/clifm/colors) should also be checked, when there is no user-provided file. This would allow to package extra color schemes, because right now, users are advised to git clone and copy files to COLORS_DIR manually.

At a quick glance, the following changes should be made to the code (just a rough quick'n'dirty sketch):

@@ colors.c @@
-size_t get_colorschemes(void) { ... }
+size_t get_colorschemes(const char *colorsdir) { ... }
...
 sprintf(colorscheme_file, "%s/%s.cfm", COLORS_DIR,
     colorscheme ? colorscheme : "default");
+struct stat attr;
+if (stat(colorscheme_file, &attr) == -1)
+        sprintf(colorscheme_file, "%s/%s.cfm", PREFIX "/share/clifm/colors",
+            colorscheme ? colorscheme : "default");

@@ main.c @@
-cschemes_n = get_colorschemes(COLORS_DIR);
+cschemes_n = get_colorschemes(COLORS_DIR) + get_colorschemes(PREFIX "/share/clifm/colors");

I've only tried loading the themes, and did not test how it behaves when trying to modify and save them; also, the proposed code does not check for duplicates. Alternatively, COLORS_DIR could be made a list of directories, not just one, but that might be more complicated approach (e.g., it would probably require tracking of each directory's writability).

There is also an inconsistency: plugins and functions are installed into their dedicated subdirectories, but default.cfm ends up in $(PREFIX)/share/clifm, that is, without the colors subdirectory.

[leo-arch]

Hi @danfe. Absolutely true. Currently loading everything from the user's directory. But both color schemes and plugins should be read first from the user's dir, and then from the corresponding system directory. Duplicates should be checked as well, and in case one is found, load it from the user's dir. This is a quite standard approach. I will implement it.

Thanks!

[leo-arch]

One question: given the fact that PREFIX could be anything, how can I get the current one? Should I take it from the executable's path? This seems possible, but the executable could be moved to any other location not under PREFIX.

[danfe]

One question: given the fact that PREFIX could be anything, how can I get the current one?

Usually it is taken from the Makefile (e.g. you spell it as DESKTOPPREFIX), and then passed to the compiler as -DPREFIX=... macro on the command line.

Should I take it from the executable's path? This seems possible, but the executable could be moved to any other location not under PREFIX.

Right, some programs do it, but IMHO this is less favorable approach, and would also break things for people who prefer custom prefix for data files (so executables and data live in different locations which might not even share any common subpath).

[leo-arch]

Already implemented DATADIR in the makefile. Even thus, the makefile could be wherever, and even totally absent from the system, so that I should not take this for granted.

Perhaps I should just check for common datadir values, such as /usr/share and /usr/local/share. For those preferring a non-standard datadir, well, they just need to copy colors and plugins to the user's dir.

[leo-arch]

Well, it should be working now. I added checks for DATADIR, for both plugins and color schemes, checking also for duplicates. I'm not entirely happy with the implementation (longer than I thought (see cbc8abc)), but it works.

Regarding DATADIR, I finally opted for this approach:

1. Check executable's path and try to get DATADIR from there. If not found:
2. Check commonly used (almost standard) dirs (/usr/share and /usr/local/share).

I guess this should be enough.