[bt-devel] Config system

[Gary Holmlund]

Eeli Kaikkonen wrote:
> Eeli Kaikkonen wrote:
>
>>
>> At the same time I have planned a new config system. I'll try to 
>> implement it so that it can be used for creating the actions without 
>> messing up the old system. Then people can see if it's good or not.
>>
>
> Here is a draft attached. It's not complete or functional yet. It's 
> undocumented on purpose: if you can easily understand how it works, 
> it's easy to use.
>
>
> Pros:
>     - very simple public interface, easy to use
>     - it's simple to add a new config item (vs. the old system 
> which       is incomprehensibly difficult)
>     - const values and mutable settings with the same interface
>       (vs. the old system which has CResMgr and CBTConfig)
>     - string keys can be passed as arguments (namespaces can't which
>       is a huge disadvantage in the current system)
>
> Cons:
>     - uses runtime memory to store key names (namespaces in the old
>       system don't take space)
>     - adds some runtime speed penalty
>     - no compile time checks
>
> Answers to cons:
>
> Memory consumption is not a problem. Any module takes much much much 
> more memory. The old system uses runtime memory, too, though maybe a 
> little bit less.
>
> Runtime speed is not a problem. Graphical UI is much more costly, not 
> speaking of html rendering. If a setting is used more than once in one 
> place it can be put to a local variable instead of calling 
> BtConfig::get().
>
> Compile time check has some value. However, as far as I know there 
> exists no system which has good sides of both: compile time check and 
> runtime simplicity. The current system has lost simplicity and gained 
> little. The new BtConfig is between the two: it has strict runtime 
> checks hidden in the implementation but very simple public interface.
>
> You can use a key only if it has been set in init phase - this 
> prevents accidental typing errors if the code is ever tested even 
> once. Every key must have an explicit default value. The value can be 
> set only with the correct type even though QVariant itself is not 
> strict about types. Faulty type is also caught runtime if the code is 
> tested even once.
>
> As I said, this hasn't been tested. I may have missed even something 
> obvious. Feedback is needed.
>
> --Eeli Kaikkonen
I believe I see where you are headed with this. I have not had a chance 
to think about it to much.

In the mean time, I have tried to change from KApplication to 
QApplication, but it looks like I can't do it until KActionCollection is 
gone. It depends on some data setup by KApplication. Perhaps we should 
pull it out now.

Gary