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
andquickmark
with positional argumentsaction
andname
action
is one ofadd
,load
anddelete
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!