KFileMetadata extractors. Though, the actual code is already sufficiently separated, only the repository contains to many implementations with too many dependencies. Probably plain text and text based (e.g. xml) extractors should stay in the main repository, while extractors requiring a lot of third party (ffmpeg, exiv2, ...) code should move into a separate repository.

In T11553#253693, @ahmadsamir wrote:

The current API is suboptimal, as it flattens all properties.

In D17816#677552, @ngraham wrote:

What is the status of this? How do we move forwards? I know this has gone on a long time and we're all getting tired, but I think we can push this past the finish line without too much trouble, hopefully. :)

In T13631#251183, @ngraham wrote:

You want packaging changes, not source changes

That's kind of the problem; some distros don't do the right thing here, and contacting every distro is not really feasible. Yes, you can say, "well X distro does it right, people should just use X distro", but that's not a realistic perspective given that we encourage our software to be widely packaged. The perspective I'm coming from is that of trying to improve the user experience for all of our users, not just those who choose distros that are well-packaged. I see the fact that our software can be mis-packaged as a problem in the first place.

@soredake - You are barking up the wrong tree. You want packaging changes, not source changes, i.e. install the plugins as soon as dolphin is installed. Talk to your distro maintainers to make this happen.

Pulling e.g. the thumbnailers into kio is a complete no-no. They have all kinds of third-party dependencies.

In D17816#677455, @kdudka wrote:

@bruns I find your attitude unnecessarily hostile. If you think that the code is perfect as it is, feel free to patch it case by case until it eventually works for everybody. That is your choice.

In D17816#677453, @kdudka wrote:

I do not think we have to. Please have a look at how attr_copy_fd() from <attr/libattr.h> is implemented: http://git.savannah.nongnu.org/cgit/attr.git/tree/libattr/attr_copy_fd.c?id=a4187bec#n111 This code is quite mature and it is used by cp(1) on GNU/Linux for instance. I do not think that KDE users will appreciate some blindly coded fancy features on top of that when the basic functionality gets totally broken as a result of these experiments. Please keep the code simple and reliable.

In D17816#677451, @kdudka wrote:

The man page says that one has to check return value of the second call. It does not say that the function needs to be called in a loop indefinitely until it succeeds.

In D17816#677449, @kdudka wrote:

Even after applying the proposed patch, the code still looks problematic to me. I would prefer to have it explained first. When fgetxattr(..., 0) returns -1/ERANGE, what is the point of calling fgetxattr(..., 0) again? It is still going to busy-loop indefinitely in this case, doesn't it? How many times do we actually need to call fgetxattr() on a single file descriptor? Twice? Then unbounded loop is not the best construction to begin with.

PreviewJob uses ThumbCreator, which uses QWidgets to do the plugin specific configuration. Currently, it opens a dialog on a configuration request and expects the same dialog passed in again (as QWidget*) to apply/save a configuration change.

But this also means we no longer have process isolation. May be important for everything using third party libraries, e.g. the thumbnailer, and also probably metadata in general (see https://invent.kde.org/network/kio-extras/-/merge_requests/51)

Looks ok to me now. Can someone else please double check?

One possibility to hide it would be the x-gvfs-* options, though I am not sure if it is possible to pass these to fuse.

From me also a -1, mostly because of the dependency tree. Stuff like ffmpeg and Samba have a *huge* dependency tree.

In D29526#676402, @meven wrote:

In D29526#676386, @bruns wrote:

For all but text the DPR is completely irrelevant, large@1 is identical to normal@2.

Yes and that's up to thumbnail creators to decide. To take advantage of this, we would need to introduce some ThumbnailCreator type that would say whether or not generated thumbnail might be influenced by DPR (i.e) text. That would necessitate change the ThumbnailCreator API.

In D29397#663902, @broulik wrote:

At the risk of asking a stupid question, why?

The text thumbnailer should be able to produce readable text on high dpi, or the folder thumbnailer should render the folder icon sharply and the picture frames non-pixelated

For all but text the DPR is completely irrelevant, large@1 is identical to normal@2.

Most thumbnailers are completely DPR agnostic, and will create identical thumbnails for large@1 and normal@2. Having both is a waste of disk space and CPU time.

In D28745#676320, @marcingu wrote:

In D28745#676317, @bruns wrote:

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

The whole block can never return true, so it should just be removed, along with all its dependencies.

I tested it once more and it returns true when it should, as expected. What makes you think it doesn't?

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

@marcingu - have you even verified this works? - I am quite sure it does not, neither for fuse.encfs, fuse.cryfs (as used by Vaults), nor for any LUKS encrypted devices.

In D28745#675698, @marcingu wrote:

How often do I have to repeat the thumbnailer has to use the canonical path anyway? Please use that.

storageAccessFromPath converts given path into canonical. I figured it should do so anyway, so I'm not doing it again here.

In D28745#675685, @marcingu wrote:

Solid::Device device = Solid::Device::storageAccessFromPath(filePath);
if (device.is<Solid::StorageVolume>()) {
    allowCache = device.as<Solid::StorageVolume>()->usage() != Solid::StorageVolume::UsageType::Encrypted;
}

In D28745#674863, @meven wrote:

In D28745#674827, @bruns wrote:

In D28745#674711, @meven wrote:

Solid does not provide straight folder => StorageVolume yet, but I think Solid could have such a utility feature added.
Something like Solid::Device::findByPath(), it would need to canonically and recursively resolves the path parent to pay attention to symlinks.
This would also help D26407

No recursion needed, stat provides the device.

Only when the file is not a symlink, if so we need to check the symlink target recursively, that's what I meant.

And can you please use arc to upload the patch - it is nearly impossible to do a review with the missing context

In D28745#674711, @meven wrote:

Your build system seems to be broken. The "missing" methods are statically linked, see src/file/extractor/CMakeFiles/baloo_file_extractor.dir/baloosettings.cpp.o

In D28745#667225, @thiago wrote:

Use Solid and ask it if the device is on an encrypted device. If Solid does not have such an API, add it.

I think the patch as is has some structural problems. I think it would be significantly cleaner when:

In D29454#664222, @ngraham wrote:

Nice!

This has been pending for more than two weeks now, without any sort of review ...

Ping!

The summary needs some text which works without any images

whitespace

Wrap at ~80 characters, please.

In D28972#657192, @meven wrote:

@bruns does this sounds good to you ?