karlch/vimiv-qt

Marks/Tags

Closed this issue · 2 comments

There should be a way to mark a list of images and saving this list under a name. It might also be nice to mark single images or library directories and saving them to a "quickmark" similar to qutebrowser's quickmark system.

Ideas:

  • The lists are saved to $XDG_DATA_HOME/vimiv/Tags
  • The lists could support a substructure, meaning it could be possible to group multiple lists into directories under $XDG_DATA_HOME/vimiv/Tags/dirname
  • The quickmarks are saved to $XDG_DATA_HOME/vimiv/quickmarks

Commands:

  • tag and quickmark with positional arguments action and name
  • action is one of add, load and delete
  • name is the name of the tag/quickmark

Quickmarks don't seem to make much sense for an image viewer, but mark is certainly still important. Commands for mark could be:

  • mark path(s)
  • mark-clear
  • mark-load to load all marked images into the filelist.

Status modules could include:

  • {mark-indicator} showing if the current file is marked
  • {mark-count} showing the total number of marked files

Some of the ideas taken from karlch/vimiv#78 of the gtk-version.

@elig0n replying here instead of in karlch/vimiv#78 as this is where the actual changes have been implemented.

I agree with the usecase of rotating many camera images as this is also why I first implemented it but to be fair I always use exif information to automatically rotate my images. Instead of making the :rotate and friend commands much more difficult, I have decided to expose marked images to the command line with the %m indicator. Therefore, if more complicated actions should be applied to the marked images, one can use external tools such as :!mogrify -rotate 90 %m.

In addition, your idea with the number of marked images as status indicator is now in the {mark-count} status module which I find great, thanks for the idea! :mark-toggle has been replaced by :mark-clear and :mark-restore.

Feel free to check out the implementation here :) If you have any other suggestions, just open another issue here.

In case you don't have any objection, you can close the issue in the gtk version as it will not be worked on. At some point when I feel the code here has matured, I will replace the gtk version as default and close all feature request issues there anyway.

Thanks again!