Improve handling of images from multiple directories

[karlch]

In principle vimiv supports opening images from multiple directories in all sorts of ways (directly upon startup, via :open, via marks, via tags, ...), but the behaviour is then often inconsistent or buggy. Here are some of the issues:

• the library display the directory of the first image, not all images
• only images in the directory of the first image are tracked by the working directory handler. Therefore deleting/changing any of the other images is not communicated back to vimiv.

The expected behaviour of the library is up for discussion. The initial design was meant as a fast browser to search the filesystem and open images similar to using ranger. Open questions are:

• what should the library display if images from multiple directories are opened?
• where should going up a directory (i.e. :scroll left or press h) go in this case?

Obviously all opened images should be tracked by the working directory handler. The how is currently not clear though. One option proposed by @jcjgraf is to use a virtual directory which contains all opened images and track this via the working directory handler. We would need to take a look at the complexity of this, possibly it could also solve the library inconsistencies if placed at a logical position in the file hierarchy.

Branched off from #293

[jcjgraf]

I have spend some time thinking about this particular issue as well as about the library mode on itself and the interplay with the other modes. Reading the docs, some issues as well as from my personal experience, I think that there is a conflicting view between what it is designed to to and what it is required to do.

If I understand you @karlch correctly from reading the docs and your perspective in some issues, library mode is designed as fast means of browsing directories and opening the desired image. Apparent from #14 all its functionality could be mimicked by the command :open.

Later on it was requested that additionally to opening images, library mode should also synchronize selection with other modes so that it can kind of be used to keep the overview over the images while browsing through the images in thumbnail/image view. This makes also lots of sense since unlike e.g. thumbnail mode, library mode ban be used next to image mode (have both of them open at the same time).

An then there is me coming and complaining that library mode does not properly reflect opening images from multiple directories using :open. 🙃

All in all, I would say that library mode was build to open images, but in addition also required to reflect the current working set (list all open images, synchronize movements to keep an overview of the open images etc.). In my view, these two tasks cannot really be merged into a single mode in an intuitive may.

So, if we would like to implement that in a intuitive may, we would have to separate the two functions;
Library mode is solely used to to browse the directory and open images. When we open a folder, all images contained in this folder are represented by the "current working set". In image/thumbnail mode we do not browse the images of the folder, but the images in the current working set. So, the current working set sits between the library mode (directory structure) and the image/thumbnail mode and kind of forms a layer of abstraction. When we are in image/thumbnail mode and want a (synchronized) list of all open images, we do not use the library mode for that anymore, but some dedicated list which displays all images of the working sets.

The key advantages:

• Working set can easily represent images from multiple directories.
• Possibility to easily add/remove images from the working set.
• Intuitive synchronized list for image/thumbnail mode representing all open images with a simple key binding to toggle this list.
• Image/Thumbnail mode do not care about the directories where images come from but just about the images in the working set.

The only disadvantage I see is the potentially large amount of work this would require to add...

Probably, this soulds all really confusing. Let me know if I have to futher elaborate.

These are just some random thought from my side about this issue. I am not sure if these are pure illusions and completely of from what is reasonable to do. Due to its complicity of the code I do not really have a deep understanding on how everything is currently implemented and what changes would we required. So I comment merely from the UX point of view.

[karlch]

I fully agree that library mode has been taken a bit out of its original scope, but I am not sure if it could not be improved to do what one would expect from both tasks. Let me see if I understand your proposal correctly, before I go on.

How and where would you display the list of the "current working set"? I feel like this could duplicate quite some of the library code, unless you were thinking of some completely different "view". In case it would look similar to the library, I feel like it would add more confusion instead of taking it away.

Would this list have any additional functionality except for viewing, e.g. should one also be able to select the image to open from there?

All in all, I somehow think this would add more complexity than it would solve..

[jcjgraf]

Maybe I have overcomplicated thinks a little once again ☺️ What I was referring to as current working set seems to implemented with the filelist and signals passing new images around. So we do not have to reinvent the wheel there.

Indeed, the working set listing has lots common with the current library mode; it should also be a vertical list of all files. In addition to the plain filenames, it would be useful to have a single column of thumbnails (very similar to the filmstrip like image listing programs like Lightroom, Darktable, Rawtherapee etc. have, just vertically instead of horizontally.). While in image/thumbnail mode this listing should easily be toggleable with a single shortcut.
Also, I do not think that this listing should be a fully-blow mode which we can "enter" but it is sufficient to have a "read-only" list (not clickable, no special functionality etc.).

Having the library mode and the listing combined has also the disadvantage that once you change directory in the library without opening any images, in order to get the filelisting of all currently open images, you have to manually navigate back to the currently opened folder.

Maybe the simplest thing would we to split the current library mode into a library mode (only for file browsing as initially designed) and into a (read-only) synchronized list, listing all opened images. I think using this approach we could bypass many odd conditions which we would have to handle when adapting the library mode to reflect opened images form multiple directories. I.e. problems like "What directory opens when you navigate one folder up while having images from multiple directories open?" or "Once navigated into a different folder, how can you get back to the filelisting of all opened images?" would be resolved.

I think when properly thought through and implemented, this would reduce complexity and improve the user experience.

[karlch]

Hmm, I like some of where this is going, but am somewhat afraid of adding more confusion.

When reading through this, it sounds like most of this could be implemented with the current thumbnail mode when just changing the layout to a list and adding the names. What would the point of this listview in thumbnail mode be, where we have all images shown anyway?

Basically where I am going is, could the current thumbnail mode solve all of the above, as it already has the filelist loaded, even with thumbnails, if:

• We add a setting to display the basename of the file in addition to the thumbnail
• We add a setting to display the thumbnails as a list of images vertically on the very right of the current image, much like the filmstrip you describe
• Optional: we add a setting to hide the thumbnails when in "list view"