[bt-devel] Config system

[Eeli Kaikkonen]

Martin Gruner wrote:

> -Unifying CResmgr and CBtConfig in a new system is great, but CProfile works 
> well and should not be changed now just for the sake of changing it. Please 
> leave it as it is, we can take that step later on.

There should be no need to change it radically.

> -adding a Signal/Slot mechanism to the config seems to be a great enhancement 
> for me.

...though it's useful only if other classes use it, and there's no need 
to change that aspect of the working system right now.

> -If we drop the compile-time checking for settings names, we should have a 
> runtime check that causes BT to crash when trying to access an unknown setting 
> (an assert). That should prevent spelling mistakes.

That exactly is taken care of in the proposal which was attached to my 
earlier post.

> -The new and old systems cannot really coexist. It needs to be a replacement, 
> and that must make sure all of the user's (important) settings are migrated, 
> if you have to change the format. We already have a small framework for 
> upgrades like this.

I have to research this a bit further, but I suppose they can coexist 
for a while. Probably they can both use the same QSettings object. The 
ultimate reason why I brought this up is that we need to port the 
actions and I want to make it easier. Fortunately they don't use the old 
config system for saving settings at all. It means that we can use the 
new system for const settings (icon name) without any concerns. The 
shortcuts were taken care of by KDE and have not been migrated as far as 
I know; now they can just be added to the config file.

> -Using QVariant, does that mean that I need to cast the values wherever I want 
> to use them? Maybe you want to provide some convenience wrappers that do the 
> conversion already, like value() (Variant), intValue() (int), stringValue() 
> (QString) and so forth. What do you think?
> 

In the mentioned proposal there are only one getter and one setter. The 
setter works without explicit casting. The getter returns a QVariant 
which you have to "cast" with toXXX() method. It can't be made easier 
than that because when getting a value you must to know the type and use 
it in the code in some way or another: either QVariant::toXXX() or 
BtConfig::getXXX(). It's much simpler to use QVariant::toXXX() because 
then we don't have to write one getter for each type.

Another option could be to use a template for getters, but I don't see 
any advantage in that.

> Now, given that this means quite some work (=time), and has to be complete to 
> be releaseable, I'm not sure if it would be the right time now to work on 
> this, but I cannot decide this for you.
> How about creating a branch for this change that allows you and others to 
> collaborate in SVN? Whenever things are near complete, we can merge this 
> branch. But note that the longer it remains open, the more difficult the merge 
> will be.
> 
> Right now I think that it would be better to work on the Qt port instead. This 
> would allow me and others to start working on releases for different platforms, 
> while you keep working on the inner refactorings. Just a suggestion, that also 
> depends on how much time you will have.
> 

As I said, I'm trying to make porting Actions easier. It doesn't mean 
that this is less work, but I hold the porting work in mind all the time 
(I already studied that today). Let's also see how Gary goes on with the 
ActionCollection and Application. I can leave the config system waiting 
if needed.


--Eeli Kaikkonen