[bt-devel] Config system

[Gary Holmlund]

Eeli Kaikkonen wrote:
> Martin Gruner wrote:
>> -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.
>
I think I would favor multiple access functions. The .toString function 
is not providing type checking. Here is a quote from QVariant:

"Returns the variant as a QString <qstring.html> if the variant has type 
<qvariant.html#type>() String <qvariant.html#Type-enum>, Bool 
<qvariant.html#Type-enum>, ByteArray <qvariant.html#Type-enum>, Char 
<qvariant.html#Type-enum>, Date <qvariant.html#Type-enum>, DateTime 
<qvariant.html#Type-enum>, Double <qvariant.html#Type-enum>, Int 
<qvariant.html#Type-enum>, LongLong <qvariant.html#Type-enum>, 
StringList <qvariant.html#Type-enum>, Time <qvariant.html#Type-enum>, 
UInt <qvariant.html#Type-enum>, or ULongLong <qvariant.html#Type-enum>; 
otherwise returns an empty string."


1. If the QVariant value was an int, but you request a string you will 
get a string, not an error.


2. Inside a typed access function you can test the type of the QVariant 
and Assert that it is of the right type.

3. Did it return an empty string because the string value was empty or 
because it was an invalid type to convert to a string?


4. With a typed access function you will you will probably do less 
checking of the value after the access function is called. This will 
make the code somewhat cleaner where the access function is used.

>> 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.
I am not sure why it makes the Action porting easier. The actions are 
created in the various window classes using values from the CResMgr. The 
value of the new config system for Actions comes in when we are ready to 
values other than the default value. That is when we would have a 
ShortCut editor, not now. Here are a couple of lines that illustrate 
getting a default value for an Action from CResMgr:
    kaction = new KAction(tr("Previous chapter"), a);
    
kaction->setShortcut(CResMgr::displaywindows::bibleWindow::previousChapter::accel);
 
Since we are not using the KDE ShortCut editor, the only function of the 
KActionCollection class is in providing a container for Actions and a 
method of looking them up by a name. Even this functionality is not 
needed until we write the ShortCut editor.  So, KActionCollection is 
doing NOTHING for us right now. It can be deleted without any loss of 
current functionality.

The value of replacing KActionCollection with a BtActionCollection 
(which would be a container with named access to actions) only becomes 
important when we start writing a ShortCut editor.  The BtConfig system 
may provide  an alternate  way to  access  actions  by name, I am not sure.

I think the right order for me to proceed is:

1. Convert KActions to QActions
2. Delete the KActionCollection and not replace it.
3. Get back to replacing KApplication with QApplication.
4. Do the About dialog.

I don't think these tasks will be very long.

Gary