Support for specifying config file and resource directory about abaddon HOT 13 CLOSED

Seems good to me!

from abaddon.

Another one to the suggestion of allowing custom css/resources under ~/.config/abaddon:

I don't think that's the right place. These files are not really config files, so they shouldn't be part of a config file directory. Same as with /usr/share, I'd suggest allowing them to be put under ~/.local/share (or rather ~/.local/share/abaddon of course^^). That way, the distinction between config and resources is clear and the local directory structure (~/.config for config and ~/.local/share for resources) reflects the system directory structure (/etc for config and /usr/share for resources). I am really not a fan of putting anything else than config under ~/.config as some people like to manage their config files using git to synchronize or share them between machines. While could definitely belong into that category, custom icons etc. most certainly don't. It's already bad enough that OBS puts whole binaries (the plugin .so files) in their ~/.config directory and all Electron Apps have the urge to ignore that there is ~/.cache and rather put their caches inside ~/.config which makes cleaning up all those hidden directories below ~ a real pain in the ass.

Those directory structures are there for a reason and I am very happy that abaddon starts to follow them in the system/global scope. Now I'd really like to see the same happen in the per-user scope.

Anyway, +1 for supporting custom CSS/resources on a per-user level and thank you for having implemented the new config file detection so quickly!

from abaddon.

i added the resources branch. it should pull css and res from /usr/share/abaddon now if present or fallback to the cwd. it should also now pull abaddon.ini from ~/.config/abaddon/abaddon.ini if it's not in the cwd too. i'll probably add an environment variable for overriding the config location too since i dont want to deal with parsing a command line

as for the configure_file idea i'm not really familiar with that side of CMake so that might take a little bit of figuring out. is there any reason why that would be a compile-time thing instead of runtime like the config file? (i guess its more useful to change the config at runtime or something)

lemme know what u think

from abaddon.

What do you think of pulling css and res from ~/.config/abaddon/? This way, different users in the same machine can have different styles.

from abaddon.

What do you think of pulling css and res from ~/.config/abaddon/abaddon? This way, different users in the same machine can have different styles.

yeah that can be done. i guess the priority for this then should be the working directory, then that path, and then from /usr/share?

from abaddon.

from abaddon.

Well, in that case it shouldn't be that hard. It can be as simple as
checking argc and then just taking argv[1] as the path to the config
file (if specified, of course–that's what you check argc for).

yeah that'd be the obvious way but it'd cause problems further down the line if i ever decide to add more command line options. i already added an environment variable (ABADDON_CONFIG) option so i'll just stick with that unless there's some important benefit for adding it to the command line

as for the resource dir stuff i don't know too much about how linux's file hierarchy works but i think i can figure out what you've said here. in that case i guess the hardcoded /usr/share/abaddon (e.g. here) would be replaced with that preprocessor definition (the default being /usr/share/abaddon)?

and when you bring up CMAKE_INSTALL_PREFIX does that even apply here? i've never tried making something ninja/make install-able but i'd figure that's something i would have to manually add to CMakeLists. or is this something i don't even have to care about if i do the configure_file stuff

from abaddon.

Yeah, if command-line-parameters shall be reserved for future use, an environment variable is not a bad idea. On the other hand, one might also use something like getopt(3) or Boost program options for command-line parsing. Just to give you an idea, what you can use for the job.

in that case i guess the hardcoded /usr/share/abaddon (e.g. here) would be replaced with that preprocessor definition

I am already concerned that you say “e.g. here”. Such things should occur only once in the whole source tree–preferably in some header file which contains all the constants or in a header file of the only class using a certain constant. It's a bit of work to do that initially, but it really pays out if you ever need to change something (like now) or if you'd like to have an easy time with unit tests.

But yeah, in that case you would have something like

#define DEFAULT_RESOURCE_DIR "@CMAKE_INSTALL_PREFIX@" "/abaddon"

or

#define DEFAULT_RESOURCE_DIR "@ABADDON_SYSTEM_RESOURCE_DIR@"

(given you have a CMake variable ABADDON_SYSTEM_RESOURCE_DIR which contains the desired resource directory)

does the job. You can theoretically do the same for almost anything which you might want to configure at compile-time (e.g. optional features, OS-dependent code paths, etc.). Just don't over-use #ifdef and its friends–that can make the code very error-prone as you theoretically have to test it for every combination of enabled/disabled options.

i've never tried making something ninja/make install-able but i'd figure that's something i would have to manually add to CMakeLists. or is this something i don't even have to care about if i do the configure_file stuff

Yes and no. When preparing your code for system-wide installation, you start making the code respect the prefix path (like /usr in this case) for certain things (e.g. to find the resource directory). But the install itself is just telling CMake which files to install where and with which permissions.

(this part is a bit off-topic)

You might want to have a look in a few resources regarding CMake installs:

• https://cmake.org/cmake/help/latest/command/install.html
• https://stackoverflow.com/questions/48428647/how-to-use-cmake-to-install
• https://www.foonathan.net/2016/03/cmake-install/
• https://stackoverflow.com/questions/6241922/how-to-use-cmake-install-prefix

(most resources deal with installing libraries, but executables work in a similar way–they are even easier to install)

And if you'd like to install files, you can have a look at this–although I recommand using GNUInstallDirs to get the right directories presented as CMake variables.

PS: You might want to move this to a separate issue if you intend to support installation using CMake as there is some more work to do before you can do a proper installation with it...

from abaddon.

I am already concerned that you say “e.g. here”. Such things should occur only once in the whole source tree–

well in my defense it's already only in one place :^) but yeah i know what you mean

i don't want to concern myself with the cmake install stuff right now but i might come back to it in the future

anyways i'll have a go with the configure_file stuff and i take it that should be it then?

from abaddon.

I've just tested the resources branch. Loading resources from /usr/share and config from ~/.config/abaddon/abaddon.ini seems to be working fine. However, the following command-line cause abaddon to fail to create a config file:

$ ABADDON_CONFIG=/home/nex/build/abaddon/build/tmp ./abaddon

The message show was:

The settings file could not be created

from abaddon.

However, the following command-line cause abaddon to fail to create a config file:

$ ABADDON_CONFIG=/home/nex/build/abaddon/build/tmp ./abaddon

The message show was:

The settings file could not be created

the environment variable expects the path including the filename so it's failing to create it because it tries to create a file called tmp in build

i think your explanation about the home folders makes sense, i'll change the path for the resources out

from abaddon.

any more input on this? i'd like to merge it to master now since everything seems to be functioning as expected

from abaddon.

It looks good and ready to merge to me.

Thank you for your efforts!

from abaddon.