Rockbox

Tasklist

FS#10183 - rbutil settings with static accessors

Attached to Project: Rockbox
Opened by Dominik Wenger (Domonoky) - Saturday, 02 May 2009, 21:52 GMT
Last edited by Dominik Wenger (Domonoky) - Saturday, 09 May 2009, 16:59 GMT
Task Type Patches
Category Rbutil
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Here is a first attempt to static accessors for the RbSettings Class.

This removes the need to pass settings pointers around. And the settings are always accessible.

This task depends upon

Closed by  Dominik Wenger (Domonoky)
Saturday, 09 May 2009, 16:59 GMT
Reason for closing:  Accepted
Additional comments about closing:  Improved and commited.
Comment by Dominik Riebeling (bluebrother) - Sunday, 03 May 2009, 13:32 GMT
I had a look at that patch and a few questions about it:
- why this split with creating a RbSettings object through the static access functions and accessing them through that object? This seems too complicated to me. Everything we need for this to work are the two QSettings objects and pointers. Why don't you create two static QSettings pointers and make sure those are initialized (with ensureRbSettingsExist()). Then the only thing that needs to get changed is checking that before doing any access handling.
- those "p_" prefixes for private members is weird -- I've never seen that before, and the rest of Rockbox Utility code doesn't do that either. Why? It looks confusing (plus, if you remove the split I mentioned above I don't see any reason for having static and private access functions)
- and for minor nitpicking, platform isn't written with "tt" in english ;-)

Loading...