Open paolobenve opened 6 years ago
I don't understand the use case for this issue. What is the goal? It will make the config file more complex. Is it worth the benefits?
perhaps the installer could prefer an hidden file in order to have an easy way not to count them with the media files.
It doesn't seem that a big complexity is added, the hardcoded 'album.ini'
string is going to be substituted by something like Options.config['album_ini_file']
. In bash scipts the option can be retrieved easily, another option is retrieved already from options files
OK, I understand now. I usually don't like hidden files because they are mostly invisible and so easy to forget they're there...
I'll do it soon.
Meanwhile, if you want to count the media files without counting album.ini
, you can use something like find ~/Pictures -type f \( ! -name 'album.ini' \) -printf x | wc -c
Do you prefer retrieving the album.ini
filename from the config file of from command line options?
I see I'm not consistent here as I argued in favour of using config file instead of options with js-css-minify.sh
... But now, the user needs to give a directory name as an argument too.
It would be more Unix having make_album_ini.sh -i .hidden.ini ~/Pictures
instead of make_album_ini.sh /etc/myphotoshare/myphotoshare.conf ~/Pictures
.
On the other hand, using the config file insures the name is correct. All scripts from MyPhotoShare use the same information.
What do you think? We can still rollback using options it it's more consistent.
I think it's better to retrieve it from config file, so that it holds all the info for the album tree
make_album_ini.sh
was a quick hack for creating album.ini
files with default sections in a single directory (typically the last photo shoot). It could be used to parse a whole album tree with find
in case the user wanted it, with something like find ~/Pictures -type d -exec make_album_ini.sh {} \;
.
If we want to extend it to parse the whole album tree and use configuration options (like change album.ini
name), in that case it would be better to re-implement it in the scanner
. There could be a myphotoshare.conf
option that when the scanner
encounters a new album it creates a default album.ini
file, or it updates an existing one if it finds new media. We'll be able to add advanced options, like selecting what type of metadata to include in the skeleton album.ini
. It'll be easier in Python than in Bash.
I'll add a quick fix option to make_album_ini.sh
to allow specifying album.ini
filename and for you being able to use a hidden file. It should be ready for version 3.4.
For a future version 3.5+, I'll think about re-implementing it into the scanner.
There could be a myphotoshare.conf option that when the scanner encounters a new album it creates a default album.ini file, or it updates an existing one if it finds new media.
I do not agree to make the scanner create/modify the album.ini
files.
Till now the scanner has respected the albums tree, and I think this is a secure approach that is worth being continued. Adding/modifying the album.ini
files is adding/modifying content to the albums tree, I think we cannot expose the user to the risk of damaging its media collection.
The approach of the bash script - or perhaps, better, a separate python script - leaves to the power user the freedom to take a potentially dangerous action. While the scanner is going to be launched from a cron file, this script can run manually, or the user assigns it to a cron job according to his needs.
Give the installer the freedom to use another name for the
album.ini
files, namely adding an option in the config file