Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes

[Aleix Pol Gonzalez]

> On April 22, 2015, 4:53 p.m., Matthew Dawson wrote:
> > src/kconfig_compiler/kconfig_compiler.cpp, line 100
> > <https://git.reviewboard.kde.org/r/123367/diff/3/?file=361168#file361168line100>
> >
> >     Is there a reason not to generate Q_PROPERTIES for all classes, or at least do it by default?  This seems like a useful thing to have every class use, so adding another configuration only reduces its visibility.

To minimize changes. I agree it would be interesting, I can do it if you (collectively) are on board.

Do you have an idea of what should the setting be called instead? DoNotGenerateProperties?


> On April 22, 2015, 4:53 p.m., Matthew Dawson wrote:
> > autotests/kconfig_compiler/test13.h.ref, line 38
> > <https://git.reviewboard.kde.org/r/123367/diff/3/?file=361162#file361162line38>
> >
> >     I'm not sure if brightnessChanged is the right signal to use here, as calling setBrightness won't trigger it.  I'm not sure if users would expect it to change then, or when this object actually gets saved.
> >     
> >     Thoughts?

That makes sense. I'll look into that.


- Aleix


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123367/#review79346
-----------------------------------------------------------


On April 22, 2015, 4:51 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123367/
> -----------------------------------------------------------
> 
> (Updated April 22, 2015, 4:51 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> -------
> 
> The generation of those classes makes it useful to have these being used within C++ application. This change makes it possible to use these classes from QML as well.
> 
> For each variable, exposes the getter. In case there's a setter, it will add a notify signal and the setter to the property.
> 
> 
> Diffs
> -----
> 
>   autotests/kconfig_compiler/CMakeLists.txt 0cca605 
>   autotests/kconfig_compiler/kconfigcompiler_test.cpp 43623ce 
>   autotests/kconfig_compiler/test13.cpp.ref PRE-CREATION 
>   autotests/kconfig_compiler/test13.h.ref PRE-CREATION 
>   autotests/kconfig_compiler/test13.kcfg PRE-CREATION 
>   autotests/kconfig_compiler/test13.kcfgc PRE-CREATION 
>   autotests/kconfig_compiler/test13main.cpp PRE-CREATION 
>   autotests/kconfig_compiler/test_signal.cpp.ref 58e73ef 
>   autotests/kconfig_compiler/test_signal.h.ref 19b8b40 
>   src/kconfig_compiler/kconfig_compiler.cpp 5aae340 
> 
> Diff: https://git.reviewboard.kde.org/r/123367/diff/
> 
> 
> Testing
> -------
> 
> KConfig tests still pass.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150422/de456cd7/attachment-0001.html>