DirViewer - preview icons for directories

[xeruf]

It would be nice if folders also had preview icons. On Windows it could be determined using a ".desktop"-file if it exists, otherwise look through the content and grab up to 4 icons of files in it and display them in a mini grid, that is how it is often done. There should probably be an option to disable it though due to the high I/O involved. One should also consider caching icons.

[sghpjuikit]

Feature has been implemented. Put an image cover.* file in a directory. Supported are all the formats imageio supports, so all basic formats, including stuff like animated gifs, psd or even krita files.

I will improve the documentation.

Closing as delivered.

[xeruf]

This is not what I am talking about. The feature you mentioned does make sense for a player, but this is a multiapplication and thus should also support other cases. For example if you have a gallery, there is no "cover"-image. Instead, if that does not exist, I would like it to take the first 4 icons it can get from files in the folder and show them, sort of how my file browser does it:

[sghpjuikit]

Thats quite a request and it involves several nasty problems, from top of my head:

• caching, it complicates (already complicated) code and caching the image into a file will pollute the file system, like windows does it with thumbs.db. Also what size should the cached image be? If the user enlarges the tiles, there is a need for bigger icon and there is no upper limit. Hence caching is virtually pointless, unless we would decide that certain size is 'good enough'. But then in case it isnt, the performance would get even worse. I would try to avoid any sort of cache, in memory and on disk.
• memory consumption. Doing image manipulation is Java isnt the best idea.
• composition algorithm: why 4 images? why not 5, how should they be composed. There is virtually infinite strategies here and I do not want to just pick one, like because X or Y does it that way. For the beginning, I think displaying 1st image is good enough. What do you think?
• image? Audio and video can have image as well, we should not treat images separately. Adds more complexity to the mix.
• customization: this is hard one. What if I do not want such behavior? The concept of directory's image is arbitrary here, user must be able to decide this. Like: NO_IMAGE, 1ST_IMAGE, IMAGES. Then where should this go? It is responsibility of the GridView, but this is unfortunately behavior of the Cell, which is a bit weird. Etc.

And worst of all: the code for displaying items in that grid is very complicated, particularly the image stuff. It's also old, its Java, its immensely fragile, it has some bugs/misbehavior. So I will need to do some research on how to approach this.

[sghpjuikit]

Im more interested in you 'use case'. What are you trying to accomplish?

[xeruf]

Use-case: If I am to use this application for day-to-day stuff, I want it to be useful for file navigation, and that involves identifying directories at a glance without reading the text.

[xeruf]

1) Cache it in tmp, if you do it. Don't pollute directories. But it was merely an idea 2) manipulation? 3) Doesn't the way my file explorer (Dolphin) does it give you an idea? It looks nice imo. Displaying just one image often does not give you a sufficient overview of the content. 4) Yes, I mean you just take the existing icon from file extraction algorithm, apply it to some files in the directory and take the first few you get, regardless of the file type. 5) Ooof. Nobody complains about it in Dolphin either. The only reason to have customization here is performance imho.

[sghpjuikit]

0 Would displaying first image file as the directory's cover help your use case? 1 Yes slightly better. Still, caching is... one of the sacred rules of programming is to not code your own caching... I found that the hard way (in this project). 2 Yes you need to compose a final image out of multiple images. Lots of buffers, since Java has I think 3 buffers for image or something. Add to that scaling and conversion from swing to fx image and you are looking at a disaster. The memory goes poof. 3 It looks okey, but I'm looking at an implementation complexity trade off.

[xeruf]

0) It would be a start 2) I was thinking about the directories simply having a mini-grid in them, that displays up to 4 images. That way there is no composing or conversion.

[sghpjuikit]

0 Ok I will play around with the code 1 Composition doesnt mean the images must overlap, but that there are source images and another result image and an algorithm for composing them into one must be devised. The swing->javafx conversion is always necessary as javafx has nothing to do with java image facilities that image.io uses. Very unfortunate. Needless to say the loading code is already complicated, due to attempting to produce great scaling result and fast/efficient image reading.

[xeruf]

an algorithm for composing them into one must be devised

No! As I said, just display a mini-grid of individual images within the directory preview thingy.

[sghpjuikit]

I see.

[sghpjuikit]

I realized this has additional complication. Because the files in the directory may inherit its parent's cover, they must be prevented from inheriting a 'composite' cover. This really is going in a direction of customization being very necessary.

[sghpjuikit]

I'll start looking into this soon. No promises if the feature will make it.

[sghpjuikit]

I have came up with an idea how to implement this. Detail at the bottom.

displaying first image file...

As mentioned, images should not be treated special, say you have a directory of video files. It would be reasonable to expect the video file thumbnails to be used as the directory thumbnail.

just display a mini-grid...

You are suggesting the directory thumbnail to not be an image but JavaFX layout. That requires having separate thumbnail graphics implementations based on some properties of the file resource. Not good.

files in the directory may inherit its parent's cover, they must be prevented from inheriting a 'composite' cover

Not a problem. Multi-file thumbnail of a directory would not have a cover file, only cover image (or something else). Child items only inherit parent cover file.

The only reason to have customization here is performance imho.

I disagree. For example in my uses, I need/want thumbnail for directories with no explicit cover.image empty.

Implementation notes:

• Which files do partake in cover thumbnail images lookup? All direct children.
• Will some images in the cover thumbnail be empty sometimes then? No. We will iterate children, extracting their thumbnails (or null if none) until we have required amount.
• What if there wont be enough? The final thumbnail will be able to work with 0-N sub-thumbnails, N being max, probably 4.
• How will the final thumbnail be composed? I will try creating an Image composition by drawing smaller images into the target Image. If that will prove too complex I will consider using JavaFX layout, but that is a bad idea as it would necessitate abstracting away the thumbnail graphics and that would make the code big. It could have some advantages though.
• Why is customization a problem? GridView<T> display (many) value T in GridCell<T>. Value is not aware of any of this. In order for graphics displayed in GridCell<T> to not be reloaded more than necessary, the required resources are cached - in a wrapper on top of the value. So we have another abstraction:GridView<T> has many GridCell<T> has one Item<T> has one T. From Grid's point of view the values are not T, but Item<T>. Item is responsible for handling the resources, like loading thumbnail, but because it is not aware of the grid nor vice versa, it can not be configured or changed.
• So the model is broken? No. Values must be dumb and Grid must no manipulate them either. The only value it sees is the root value. That is the link.
• So how will the customization be done? Characteristics of composed directory thumbnail generation will be optionally injectable into properties of the root item in the displayed hierarchy. This is what developer will do manually, the grid will not be aware) This is how TreeView does it too - TreeItem has no way to obtain TreeCell or TreeView reference and communicates events to it by propagating them to parent, recursively, until root, upon which TreeView set up an event listener. Our case is simpler and has opposite reader-writer direction, but it is the same concept.

[sghpjuikit]

I implemented a working prototype.

• How should the composed thumbnail look like (for images 1-4)? I do not know. I will do something simple and we can tweak it in the future.

[sghpjuikit]

Implemented in b14361b.

New features:

• user can enable/disable using parent's thumbnail for files that have no cover. This is useful for video files for e.g. tv series.

• user can enable/disable composed directory thumbnails. This has couple edge cases where it does not work (e.g. audio files with cover in tag), that requires some refactoring. This also necessitates better file format support, e.g. auto-generated thumbnails for video files or pdf.

  The thumbnail composition algorithm will be improved once we have a solid idea how it should look like. We can discuss it in this issue, though I'm still closing it.