Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79510 --- Ship it! Ship It! - Matthew Dawson On April 25, 2015, 3:38 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 25, 2015, 3:38 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 25, 2015, 11:42 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Matthew Dawson. Changes --- Submitted with commit 97552ff2ecd13eb4398231650e2f719f7a7ba052 by Aleix Pol to branch master. 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79507 --- autotests/kconfig_compiler/test13.h.ref (line 55) https://git.reviewboard.kde.org/r/123367/#comment54320 I mean to only avoid creating the brightnessChanged signal, since it isn't necessary to make this patch work. brightnessModified, being required, is fine. I'm only thinking of this as an optimization, and I'm not that worried about it anyways. Also, I don't mind commiting the removal of that signal after this lands, as long as it happens before the release. As long as that is true, no user code would be broken. Doing it now is preferred :) - Matthew Dawson On April 24, 2015, 9:39 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 24, 2015, 9:39 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
On April 25, 2015, 3:50 a.m., Matthew Dawson wrote: autotests/kconfig_compiler/test13.h.ref, line 55 https://git.reviewboard.kde.org/r/123367/diff/9/?file=363036#file363036line55 Also, I guess brightnessChanged and usrWriteconfig don't need to be generated anymore if a signal isn't being produced. Considering how much time this has taken, I'd be ok leaving the brightnessChanged signal alone for this review, and removing it later. I don't understand what you mean. They need to be generated so that we know when it changes on a different instance. In fact, what would we win by not generating them? Or you mean we don't actually need to create the Changed signal, just trigger the modified when it's due? I thought it was ok having both signals, maybe I was in the wrong, but we need to decide whether to get it in in this patch as it produces source incompatible code. (a signal less) - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79483 --- On April 25, 2015, 3:39 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 25, 2015, 3:39 a.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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
On April 24, 2015, 8:47 p.m., Matthew Dawson wrote: autotests/kconfig_compiler/test13.cpp.ref, line 33 https://git.reviewboard.kde.org/r/123367/diff/7-8/?file=362762#file362762line33 Is there a reason this got moved back? Well, Modified needs to be called together with Changed, because it's called when it changes. Right? I left it there because it seemed to me it was fine there, am I wrong? In fact, I was thinking about just connecting Changed to modified, but I guessed this was more explicit. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79473 --- On April 24, 2015, 6:56 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 24, 2015, 6:56 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79450 --- autotests/kconfig_compiler/test13.cpp.ref (line 18) https://git.reviewboard.kde.org/r/123367/#comment54297 This needs to be wrapped with a KConfigCompilerSignallingItem so that itemChanged will be called. Check line 41 in test_signal.cpp.ref for an example of how it's used. kconfig_compiler has the code to emit it as necessary, it's just limited to signals at the moment. autotests/kconfig_compiler/test_signal.cpp.ref (line 41) https://git.reviewboard.kde.org/r/123367/#comment54296 Here is an example of KConfigCompilerSignallingItem in use. - Matthew Dawson On April 23, 2015, 8:53 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 23, 2015, 8:53 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 25, 2015, 3:39 a.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Moved the changed signal emission back to ::usrWriteConfig() 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79483 --- Ok, I think this should be last set of comments. One thing I missed, and one last thought I had looking at what the final diff looks like. autotests/kconfig_compiler/test13.h.ref (line 36) https://git.reviewboard.kde.org/r/123367/#comment54313 Sorry, I missed this change. This also needs to emit brightnessModified (while also change mSettingChanged if brightnessChanged is created). autotests/kconfig_compiler/test13.h.ref (line 55) https://git.reviewboard.kde.org/r/123367/#comment54314 Also, I guess brightnessChanged and usrWriteconfig don't need to be generated anymore if a signal isn't being produced. Considering how much time this has taken, I'd be ok leaving the brightnessChanged signal alone for this review, and removing it later. - Matthew Dawson On April 24, 2015, 9:39 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 24, 2015, 9:39 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 24, 2015, 6:56 p.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Make sure we're notified when the property changes as well. 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79473 --- Looks good, one last comment: autotests/kconfig_compiler/test13.cpp.ref (line 33) https://git.reviewboard.kde.org/r/123367/#comment54309 Is there a reason this got moved back? - Matthew Dawson On April 24, 2015, 12:56 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 24, 2015, 12:56 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79403 --- autotests/kconfig_compiler/test13.cpp.ref (line 18) https://git.reviewboard.kde.org/r/123367/#comment54237 This doesn't actually use the notifyFunction from above, so any external changes are not seen when the class is reloaded. Also, reusing the notify function in this manner will only cause the signal to trigger when the class is saved, AFAICS. I think just moving the emission of brightnessModified to itemChanged would work, along with an equality check. Thanks for bearing with me on all these changes :) - Matthew Dawson On April 22, 2015, 9:20 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, 9:20 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 24, 2015, 2:53 a.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Instead of emitting on write, emit when a change elsewhere is notified. 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 22, 2015, 6:07 p.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- * Create a different kind of signal that will be generated whenever the set method is called for a property, in contrast to whenever it's written to disk. * Don't consider properties as modified if the same value is set. 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79346 --- autotests/kconfig_compiler/test13.h.ref (line 38) https://git.reviewboard.kde.org/r/123367/#comment54192 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? src/kconfig_compiler/kconfig_compiler.cpp (line 100) https://git.reviewboard.kde.org/r/123367/#comment54191 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. - Matthew Dawson On April 22, 2015, 10:51 a.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, 10:51 a.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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
On April 22, 2015, 4:36 p.m., Vishesh Handa wrote: autotests/kconfig_compiler/test_signal.h.ref, line 126 https://git.reviewboard.kde.org/r/123367/diff/3/?file=361167#file361167line126 Is the move required? This is a unit test, this is how it gets generated after the patch. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79343 --- On April 15, 2015, 5:38 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 15, 2015, 5:38 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- 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. Changes --- Only initialize the hasSignals variable once we know if there's signals (after going through all the properties which might add it). Add the Q_OBJECT macro whether there's Q_PROPERTY or Q_SIGNAL. 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79343 --- autotests/kconfig_compiler/test_signal.h.ref (line 121) https://git.reviewboard.kde.org/r/123367/#comment54187 Is the move required? src/kconfig_compiler/kconfig_compiler.cpp (line 1722) https://git.reviewboard.kde.org/r/123367/#comment54188 It might be more readable, if you created a new variable called 'requiresMoc' or 'requiresQObjectMacro'. - Vishesh Handa On April 15, 2015, 3:38 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 15, 2015, 3:38 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
On April 22, 2015, 10:53 a.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. Aleix Pol Gonzalez wrote: 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? I'd just change the default to be true. Based upon what I remember about UX, double negatives should be avoided. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79346 --- On April 22, 2015, 10:51 a.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, 10:51 a.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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79347 --- Ship it! - Vishesh Handa On April 22, 2015, 2: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, 2: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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
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. Aleix Pol Gonzalez wrote: 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? Matthew Dawson wrote: I'd just change the default to be true. Based upon what I remember about UX, double negatives should be avoided. Ok, let's do it in a separate iteration of the patch though. This is going to make a huge patch as it will require changing most of the unit tests. - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
On April 22, 2015, 10:53 a.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. Aleix Pol Gonzalez wrote: 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? Matthew Dawson wrote: I'd just change the default to be true. Based upon what I remember about UX, double negatives should be avoided. Aleix Pol Gonzalez wrote: Ok, let's do it in a separate iteration of the patch though. This is going to make a huge patch as it will require changing most of the unit tests. Ok, sounds good. For that patch, it would be good to leave some unit tests not generating properties, to ensure the negative works as well. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79346 --- On April 22, 2015, 10:51 a.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, 10:51 a.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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79353 --- If the first issue doesn't fit into this commit, this has a ship it from me after the two nitpicks are fixed. autotests/kconfig_compiler/test13.h.ref (line 51) https://git.reviewboard.kde.org/r/123367/#comment54201 This looks better, but I just thought of one other case: when the underlying KConfig class gets updated and the KConfigSkeleton updates. If that isn't too much work to do here, I'd appreciate it if it's done now. Otherwise please file a bug against KConfig so I don't forget. src/kconfig_compiler/kconfig_compiler.cpp (line 1418) https://git.reviewboard.kde.org/r/123367/#comment54202 Nitpick: Please always include braces on if statements. src/kconfig_compiler/kconfig_compiler.cpp (line 1452) https://git.reviewboard.kde.org/r/123367/#comment54203 Nitpick: braces here too. - Matthew Dawson On April 22, 2015, 12:07 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, 12:07 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 23, 2015, 3:20 a.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Generate again the Changed signal for each of the properties. Also emit the Modified signal together with the Changed signal. 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79355 --- autotests/kconfig_compiler/test13.h.ref (line 20) https://git.reviewboard.kde.org/r/123367/#comment54204 Why is there no brightness property anymore? - Albert Astals Cid On abr. 22, 2015, 4:07 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated abr. 22, 2015, 4:07 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
On April 22, 2015, 5 p.m., Albert Astals Cid wrote: autotests/kconfig_compiler/test13.h.ref, line 20 https://git.reviewboard.kde.org/r/123367/diff/5/?file=362514#file362514line20 Why is there no brightness property anymore? I still see it on line 40. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79355 --- On April 22, 2015, 12:07 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, 12:07 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review79361 --- autotests/kconfig_compiler/test13.h.ref (line 20) https://git.reviewboard.kde.org/r/123367/#comment54213 Lol i'm blind - Albert Astals Cid On abr. 22, 2015, 4:07 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated abr. 22, 2015, 4:07 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
On April 15, 2015, 5:20 p.m., Albert Astals Cid wrote: properties that are read only should have CONSTANT in the Q_PROPERTY, no? I wasn't sure. Checking the implementation I see that it's using a local variable rather than fetching the information from the configuration, so it's probably actually CONSTANT. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/#review78971 --- On April 15, 2015, 5:11 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 15, 2015, 5:11 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 15, 2015, 5:38 p.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Add attribute Q_PROPERTY(... CONSTANT) 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123367: Generate Q_PROPERTY entries out of KConfigSkeleton classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123367/ --- (Updated April 15, 2015, 5:11 p.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Don't generate a signal if there's no setter. 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 (updated) - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
