my tmsu helper scripts for an image management / album generation workflow

[Dieter Plaetinck]

code: https://github.com/Dieterbe/tmsu-helpers

my workflow is pretty simple...

* I have directories with exact copies of what's on devices (digital cameras, phones, synced from other people, etc)

* from geeqie/gqview (gtk image manager) I call gtmsu to mass-add tags to files.

* using generate_albums.sh I generate cheap album directories using symlinks based on a match expression, it uses clever filenames to seamlessly meld multiple input directories.

these albums can be thrown away and regenerated at any time.

tmsu is pretty cool.. but I don't use the fusefs. i serve the generated albums on my mediastreamer etc, which works great for me.

see also a related discussion on the geeqie mailing list:

https://sourceforge.net/mailarchive/forum.php?thread_name=50DFA18C.6050304%40xsdg.org&forum_name=geeqie-devel

Dieter

[Paul Ruane]

Hi,

Thanks for letting me know. The scripts look very interesting and it's always good to see how TMSU is being used in the wild. Some kind of user interface has been at the back of my mind but the core functionality is taking up so much of my time that I have barely thought about it. I'll be interested to see how this grows.

Linking up with existing (embedded) meta data is also on the road map.

Happy new year,
Paul

[Dieter Plaetinck]

I'm not sure how useful a dedicated "GUI for tmsu" would be.  I think adding tmsu support to existing file managers, image viewers (such as geeqie/gqview), etc would make more sense.  maybe with a linkable "libtmsu" library that other programs  (including the tmsu cli app) can implement?

for me personally that's the main thing I'm missing right now: when I have a list of image thumbnails in geeqie, I would like to see straight away which tags every image has. that would make it very usable as an image album manager. (everything else, adding/modifying tags I can do with scripts, for now)

happy NY to you too. and thanks for tmsu.

[Paul Ruane]

It's a fair point. I haven't thought much about the UI but you're right, compatibility with existing file managers would probably be more useful. That said, I think what you have done with scripts is the right way to do it. The command line interface should be the way other programs interact with it and a second, library interface would add very little. To get the list of tags for a file, for example, the file manager can call into 'tmsu tags PATH' (directly or via scripts). I have tried this with feh image viewer and it works reasonably well.

[Dieter Plaetinck]

well:

* that requires a lot of resources and becomes slow with many files. say I load a directory with 1000 files, that would mean at least 1000 new processes getting spawned. I wouldn't want to hang the UI (and potentially my system) like that

* while file managers often have some support for external scripts (usually to invoke external actions), anything that integrates with the GUI (such as showing tags for each file) needs to be programmed explicitly for the file manager, and hence be compatible with the language the program is written in. so this usually means C bindings (which can still be wrapped in lua/python/... as needed)

* furthermore I'ld argue that bindings are technically superior because of the clear contract (api) which gives compile errors on most cases of incorrect use, you can pass meaningfull (typed)/structured data around, etc.  whereas generating and then parsing text output is redundant and allows many types of bugs, which only become apparent at runtime, or not at all.