Refactor KisImageConfig to disallow writting settings in read only mode
Changes PlannedPublic

Authored by dkazakov on Aug 13 2018, 8:21 AM.

Details

Reviewers
rempt
Group Reviewers
Krita
Summary

Now we have two versions of KisImageConfig:

  1. KisImageConfig -- read only type of the config, in which you can request only getters. Accessing any setter method will throw a compile-time error (due to SFINAE)
  1. KisImageConfigMutable -- fully featured version of the config object that allows setters and that dumps all the settings to the filesystem on destruction.

Implementation details:

The thing is implemeted using templates and SFINAE. The
original KConfig object is wrapped into special wrappers:
KisKConfigWrapper and KisKConfigMutableWrapper. The former
one forwards all readEntry calls to KConfig, the latter
forwards everything, including writeEntry and deleteEntry.

KisImageConfig is implemented as a template and has two explicit
specializations for KisKConfigWrapper and KisKConfigMutableWrapper.
Setter methods of the class access m_config.writeEntry, so they
become disabled for a read-only specialization, based on
KisKConfigWrapper, which doesn't have these methods.

Test Plan

Review the code and say if you like it or now. You can also try to
build it. If it builds fine and Krita starts without any crashes, then
everything is fine.

Diff Detail

Repository
R37 Krita
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 1754
Build 1772: arc lint + arc unit
dkazakov created this revision.Aug 13 2018, 8:21 AM
Restricted Application added a project: Krita. · View Herald TranscriptAug 13 2018, 8:21 AM
dkazakov requested review of this revision.Aug 13 2018, 8:21 AM

Maybe it is an idea to add to the description what kind of things this solves? Like, when do we use read-only mode for this object?

Maybe it is an idea to add to the description what kind of things this solves? Like, when do we use read-only mode for this object?

Good idea. I'll add a description. Basically, the patch solves the misunderstanding issues, like happened in this patch with KisConfig :)

rempt accepted this revision.Aug 17 2018, 9:53 AM

I don't really like the macros, but I guess there's nothing else we could do. For the rest, the naming needs a bit of attention, I think, that's noted in-line.

libs/global/KisCpp14Quirks.h
26

I guess this needs some documentation.

libs/image/KisKConfigWrapper.h
49

I'm not sure I wouldn't prefer KisConfigReadOnly and KisConfigReadWrite instead of KisImageConfig and KisImageConfigMutable.

libs/image/kis_image_config.h
32

Hm... There's already Q_DECL_*, should we namespace our DECL_* with KIS_ ? Also, DECL_PROPERTY sounds a bit like Q_PROPERTY, but that's different. KIS_CONFIG_GETTER and KIS_CONFIG_GETTER_SETTER might be clearer?

This revision is now accepted and ready to land.Aug 17 2018, 9:53 AM
dkazakov planned changes to this revision.Sep 11 2018, 12:32 PM

The think I dislike about the patch is the fact that all this weird code is inlined. Given that we include kis_config.h and kis_image_config.h almost everywhere, it might really affect compilation time. And not even talking about the general understanding by people. I will think about some other approach without templates and inlined code...

// all the functions of this class are explicitly instantiated in a special .cpp file
template <typename T>
struct Property {
    Property(const std::string &key, T defaultValue);
    virtual T get() const;
    virtual void set(T value) const;
    virtual T defaultValue() const;
    std::string key() const;

private:
    std::string m_key;
    T m_defaultValue;
};

#define MY_PROP(_name, _type, _default) \
    static const Property<_type> _name(#_name, _default)

namespace KisConfig {
MY_PROP(someNiceValue, int, 256);
}