Adapt to change in KConfigCompiler
ClosedPublic

Authored by apol on Dec 4 2019, 4:32 PM.

Details

Summary

Properties need to start with lower-case letters, otherwise QML won't
understand them.

Diff Detail

Repository
R296 KDeclarative
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
apol created this revision.Dec 4 2019, 4:32 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptDec 4 2019, 4:32 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
apol requested review of this revision.Dec 4 2019, 4:32 PM
ervin accepted this revision.Dec 4 2019, 4:57 PM

My gut feeling would be to keep the item and the property names in sync unlike now... but this is a good fix as well indeed.

This revision is now accepted and ready to land.Dec 4 2019, 4:57 PM
apol added a comment.Dec 4 2019, 8:02 PM

I'll land this for now because the alternative is to have this not working.

Maybe it would make sense to include a KConfigSkeletonItem::propertyName property? Or even a KConfigSkeletonItem::notifySignal(KConfigSkeleton*)?

Then here we could just consume the information KConfig provides.
I would prefer not to change ::name(), because if a setting is "SomethingElse", we could end up using as "somethingElse" somewhere, and that would be ambiguous.

@ervin what do you think?

This revision was automatically updated to reflect the committed changes.
ervin added a comment.EditedDec 5 2019, 6:23 AM

notifySignal would definitely make sense on the signalling items indeed. It's kind of the information we're trying to guess here. And then propertyName on base item type of course.