tagging about sxiv

[decasm]

I want tagging functionality as well. I've started working on it in my fork. My first idea is to have a file that is read in that provides a set of tag "palettes" that will be displayed. User can select a palette with numerals 0-9, and then a tag with letters a-z. Currently, I can read a tag palette file in (currently as YAML), display it, and select palettes. At first I thought I would develop a MODE_TAG that would be used in addition to IMAGE and THUMB. I think instead I'll have tagging be an "overlay" that can be used in IMAGE and THUMB.

[kaihendry]

Can you give an example of a palette in YAML for me to better understand?

[decasm]

https://github.com/decasm/sxiv/blob/master/tag.palette.yml
The numeral is used to select a palette. The label is used for display. The rest is character to string mappings. Characters are used to select a tag, the strings are stored in the image.

[kaihendry]

So if you were tagging a photograph of your back yard, you would enter keystokes '2y' ?

Are you familiar with the programme http://hg.suckless.org/dmenu/ ? It creates a simple cache like .cache/dmenu_run and I don't see why tags can't be in such a simple flat structure too. I don't like IIUC the hierarchy you're proposing Home->Yard. It could just "home" & "yard". Dmenu is super fast so adding both tags, especially if they are already known is only a couple more keystrokes.

Thanks!

[decasm]

Yes, you would enter '2y'
I am familiar with dmenu, and I think the approach you outline would work. I would encourage you to fork the repo and try it out! One advantage that my approach offers is the potential to see what tags have already been applied to an image, which I don't see being possible with the dmenu solution. I realize that my solution strays further away from "simple" than yours, and may be too complex for muennich to accept a pull request. But I think this solution will work better for my needs, so I'm going to continue with it. Thanks for the feedback.

[kaihendry]

I don't understand how you can claim the advantage. Surely you want to store the tags as EXIF metadata tags, embedding in the image, like I do? :)

[decasm]

My approach has (at least) one advantage - I can display tags that are
already in the image. There are disadvantages as well, I'm sure. And yes, I
probably will store the tags as EXIF, using libexif.

On Tue, Aug 14, 2012 at 10:13 AM, Kai Hendry [email protected]:

I don't understand how you can claim the advantage. Surely you want to
store the tags as EXIF metadata tags, embedding in the image, like I do? :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-7727011.

[kaihendry]

Trouble is I have not worked out how to store tags using exiv2. Ideally they are recognised by Flickr.

[xyb3rt]

I will not add support for tagging, because it would make sxiv too big. But from my understanding you should be able to come up with an external script based on dmenu that handles everything you want, without changing a single line of code.

[kaihendry]

Understood @muennich. Just trying to attract anyone interested in the topic here. Getting further with my "how to store tags in an image" problem: http://twitter.com/hsivonen/status/236027804272177153

[xyb3rt]

@kaihendry You also might want to post into this thread:https://bbs.archlinux.org/viewtopic.php?id=112643&p=1. Sometimes the folks in there can be quite helpful.

[kaihendry]

Took an initial stab over at https://github.com/kaihendry/sxiv/tree/tags
Most interesting thing is at https://github.com/kaihendry/sxiv/blob/tags/sxivtag

My C skills are non-existent, so showing the tags on the right bar is a little hard for me to implement.

[xyb3rt]

I am closing this, because it is not an issue.

[kaihendry]

Closing the bug prompted me to get sxiv to show tags: https://github.com/kaihendry/sxiv/commit/dd36cc27611ecff69262386912d63b1baa9df2a0
http://r2d2.webconverger.org/2013-01-06/tagging.html <-- video

I guess you'd prefer if I did the fork or what?

[xyb3rt]

What about implementing the reading of the tags in exif.c (pure C, no shell script), so that the external command and script for writing them is truly optional?

[xyb3rt]

I've just digged into the IPTC/XMP documention and specification and wished I have done so before posting my prior comment. There's no way we can have a simple read support for this (huge) thing like for the EXIF orientation information. If we really want to support IPTC keywords and tagging we have to do it as in your tags branch.

But by merging this branch into master, we would add dependencies on exiv2 and dmenu. I could not live with that. So we have to find a way to make this dependencies optional either at compile or at runtime. I do not like conditional compilation, so I would prefer the latter option. For this, we only have to ship and install your scripts in a standard lib or libexec directory and include tests for the availability of the needed commands. The ideal way of doing so would be, of course, the inclusion of some fork & exec calls in sxiv's initialization phase.

I am going to release version 1.1 in the next couple of days, as the newly added features since version 1.0 seem to have reached a stable state.

After this I will start to work on your tags branch and see if I can wrap the external commands in a way, so that they would be totally optional at runtime.

[kaihendry]

Thanks Bert for having another look at this.

I think having a way to script in rtag with its dependencies of exiv2 and dmenu, would be ideal. Instead of me prepending to win_bar_r, I would call a sxiv equiv of like how dwm's xsetroot -name works to show the tag info in the picture frame. There also needs to be way to run a script on every image load.

I'm going to focus on scripts to delete tags and perhaps uniq them next week. I should also write a script to find images of a certain tag. :)

[xyb3rt]

I've once again changed my mind after experimenting with different approaches of a configurable text area or status bar field. I'm convinced, that calling a script--supplied by the user--whenever an image gets loaded is the right answer to fulfill all of your wishes. To be honest, it is not a direct support for IPTC tags, but in combination with the already existing it_shell_command action it gives you and other users the ability to easily add such things to sxiv.

Please have a look at the userinfo branch. Per default the left side of the status bar simply shows the name of the current image. If the executable file ~/.sxiv/exec/image-info exists, sxiv will execute it whenever it loads a file--with the name of the file as the first argument. The output of the script is then shown on the left side of the bar.

This will also address older feature requests by other users, who also wanted sxiv to display additional information in its window title or status bar.

And as this change greatly improves the new status bar feature, I am going to include it in the upcoming 1.1 release.

[kaihendry]

Thanks Bert, this is great stuff. This is exactly what I wanted.

You need a Makefile rule to copy into this image-info file and somehow highlight its existence. :) 🍻

[xyb3rt]

I will update the README & man page, adding a section for the image-info script. I'm also planning to install the script skeleton into ${PREFIX}/share/sxiv/, so that users have to create ~/.sxiv/exec/image-info on their own.

Am I free to close this issue once I've merge the userinfo branch into master?

[kaihendry]

Sure. I guess fully fleshed example "tagging scripts" need to be done, externally?

Adding tags - https://github.com/kaihendry/sxiv/blob/tags/wtag &

{ false,   XK_t,        it_shell_cmd,         (arg_t) \ "./wtag \"$SXIV_IMG\"" },

Deleting tags - needs to done
Finding images by tag - need to be done ... not sure how this will work actually

[xyb3rt]

We could add your scripts to master; shipping and installing them together with some documentation into ${PREFIX}/share/sxiv/...

[kaihendry]

Sure, I'm cool with that. :)

[xyb3rt]

I've added a section to the man page for the image-info script and merged the userinfo branch.