Refactor filter building into types which can be chained up
State before was to generate functions which can be used as filter()
arguments.
State now is that there are types which can be lined up and be executed
as filters. And/Or/Not-Filters are provided and so are helper functions
to initialize objects of these filter types.
The BM module is adapted for this.
@TheNeikos can you have a look, please?
State before was to generate functions which can be used as filter()
arguments.
State now is that there are types which can be lined up and be executed
as filters. And/Or/Not-Filters are provided and so are helper functions
to initialize objects of these filter types.
The BM module is adapted for this.
Config refactor
Refactoring of the internal representation of the configuration file.
Also removes the possibility to set verbosity and debugging flag in the config file, as I consider this bad anyways and it allows us now to setup the logger earlier in the startup phase, which means more code which can use debugging output.
ImagLogger can be configured through the CLI only now
The logger instance cannot be configured through the configuration file, as this is kinda bulky to use and we can log to debug much earlier now.
Store::put_in_cache (not put_into_cache) is now called inside ::load()
if the key is not yet in the cache.
The Store::load() function cached its interface for this. It can also be
used by the other functions in the Store object to load content.
The refactors functions from the BM module into more generic functions
for all modules.
The previous state was, that there were functions in the BM module which
were used to load from the store and applying some filters.
The new state is that there are functions to generate the filter
functions which are then used to filter the loaded files from the store,
so we can apply some more functionality on the filtered list.
Homu
Matthias Beyer