In D11913#239851, @ngraham wrote:

Let's make sure we don't regress anything in this transition. We're missing "originUrl" a whole bunch of audio-, video-, ePub-, and PDF-related properties that are currently visible by default.

Let's better drop this. I can't forsee the consequences, and after you drew the version bump to my attention I don't think there is much benefit in having a white-list. It probably is not worth the effort.
What do think?

I think there's definite value in code clean-up and more explicitness, and I'm willing to work with you to make sure we don't regress anything. But it doesn't seem like a super high priority.

In D11913#239972, @ngraham wrote:

I think there's definite value in code clean-up and more explicitness, and I'm willing to work with you to make sure we don't regress anything. But it doesn't seem like a super high priority.

My main problem is: I have no idea how to test this. We need:

1. First time use simulation
2. Old config simulation

Also I have tamed KConfig only to 85%. The rest is its own will.
Currently I'm working on D11483 which also includes a fair amount of muck out, call it a rewrite. Let's come back to this when I'm done. Hopefully then we have some ideas on how test.

OK, sounds good! There's no rush on this, after all.

On second thought:
~/.config/baloofileinformationrc only records properties different from the default (=true).
As a consequence for a configured account we would have to

• Iterate over every possible property of kfilemetadata and
  • check if it set to false,
    • assume true if not.

This somewhat foils our intention of "code clean-up and more explicitness" as it adds computation ( sort of ) to the (purely) declarative approach we see here.
In the end the code as is will be more clear and expressive.

On third thought:
Sooner or later the info sets for tooltips and info panel have to be configured separately. When we see the need for that this will have to change anyway.
I'm thinking of something like the application (dolphin) telling baloo-widgets which properties it wants and how to display them. I think such an approach is more reasonable as baloo-widgets is actually a service provider and as such should make as few decisions as possible. Currently dolphin is baloo-widgets only customer, but I think it could and should be used by other applications too.

In D11897#239375, @cfeck wrote:

The real question is, why Baloo Widgets is not part of Frameworks :P