Change property selection to opt-in
Needs RevisionPublic

Authored by michaelh on Apr 4 2018, 10:01 AM.

Details

Reviewers
ngraham
Group Reviewers
Baloo
Dolphin
Summary

By default only few proprties are shown. Everything else has be selected by users.
With this new properties can be added without changing already configured info sets.

  • Adapted filemetadatawidgettest

Depends on D11882

Test Plan

make test.
To simulate a first time use, ensure ~/.qttest/ is empty.

Diff Detail

Repository
R824 Baloo Widgets
Branch
opt-in (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
michaelh created this revision.Apr 4 2018, 10:01 AM
Restricted Application added a project: Baloo. · View Herald TranscriptApr 4 2018, 10:01 AM
michaelh requested review of this revision.Apr 4 2018, 10:01 AM
michaelh edited the summary of this revision. (Show Details)
michaelh edited the summary of this revision. (Show Details)Apr 4 2018, 10:06 AM
ngraham requested changes to this revision.Apr 4 2018, 2:27 PM

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.

This revision now requires changes to proceed.Apr 4 2018, 2:27 PM

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.

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.

michaelh added a subscriber: cfeck.Apr 5 2018, 8:27 AM

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.

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