On Tue, Dec 11, 2012 at 6:36 AM, Stephen Kelly <stephen.ke...@kdab.com> wrote: > On Monday, December 10, 2012 20:46:19 Thiago Macieira wrote: >> Before we do settings for QML, we need to figure out what to replace >> QSettings with. Or, better yet, we do the two at the same time: we develop >> the new C++ and QML settings APIs at the same time. > > I agree with this, of course. > > QML functionality should not be designed in a walled-garden. 'New age' Qt APIs > should include C++ APIs as a consideration at least.
I agree with this, of course. But let me define some key terms here: Functionality: The ability to perform a specific action. API: The types which expose functionality. The reason why most QML APIs are developed separate from C++ considerations is that there's already a C++ API for that functionality. For new functionality QML and C++ APIs should be developed side-by-side where possible. Except for QtCore (or anything else that QtQml depends on), which brings us back to QSettings ;) . This means Thiago is sort of right. We first need to decide how this functionality should work (somewhat abstract from QML and C++ APIs) and then we need to develop the C++ and QML APIs for it. But I think there are two different capabilities being conflated here: Firstly the system wide fully-fledged settings access, which I believe is the one we need to redevelop completely because QSettings isn't cutting it anymore. Secondly the convenient way to store some application local settings. I don't know if QSettings is still good for that, or whether it needs to be replaced. We'll eventually need both in QML, but I think there's a much more pressing need for the latter functionality first. The question then is: do we need to start doing that functionality from scratch including a C++ API, or is QSettings still good there and QML can just build its own on top (just writing into an ini file)? One thing that I started thinking about though is that we will need in this case to have a C++ and QML API that can work with the same settings (unlike the existing Local Storage API), so that the C++ and QML halves of an application can work together properly. It doesn't mean the APIs have to be at all similar, but they need to easily load and save to the same data store per application. -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development