Review Request: Move directory related code to DirectoryProvider singleton

Arjen Hiemstra djfreestyler at gmail.com
Wed Jun 22 21:41:26 CEST 2011


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101727/#review4074
-----------------------------------------------------------



core/directoryprovider.h
<http://git.reviewboard.kde.org/r/101727/#comment3319>

    You should add a Q_OBJECT macro and include the .moc, all our singletons are QObjects anyway.



core/directoryprovider.h
<http://git.reviewboard.kde.org/r/101727/#comment3320>

    There is no need for the enum if we are using a hash for caching. So you should remove this and change userDir to accept a QString.



core/directoryprovider.h
<http://git.reviewboard.kde.org/r/101727/#comment3318>

    Now that we have a singleton, please just make these also non-static.



core/directoryprovider.h
<http://git.reviewboard.kde.org/r/101727/#comment3322>

    No need for this variable if we have the hash anyway.



core/directoryprovider.h
<http://git.reviewboard.kde.org/r/101727/#comment3321>

    Make this a QHash<QString, QString>



core/directoryprovider.cpp
<http://git.reviewboard.kde.org/r/101727/#comment3323>

    Right, I think you slightly misunderstood me in regards to how I meant use a hash for caching.
    
    What I meant is caching the full result of the dataLocation manipulation. So if you request the "games" directory, you first check if the hash has a value for key "games". If not, you do the entire data location manipulation, so you will end up with something like "/home/shaan/.local/share/data/gluon/games/", then you store that result in the hash with key "games". The next time I request "games", it will now instead return the cached location.


- Arjen


On June 22, 2011, 7:19 p.m., Shantanu Tushar Jha wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101727/
> -----------------------------------------------------------
> 
> (Updated June 22, 2011, 7:19 p.m.)
> 
> 
> Review request for Gluon.
> 
> 
> Summary
> -------
> 
> When we were adding userDir functions to GluonCore::Global, for caching and flexibility purposes it was needed to add two variables. Keeping these static was quite a mess, and I and Arjen concluded that a Singleton is more suited for this kind of stuff.
> As agreed on IRC, added a new class DirectoryProvider which has all the functions from GluonCore::Global except version because its not a directory function. Also, except the userDir function, other functions don't require an instance and can be called directly.
> 
> 
> Diffs
> -----
> 
>   core/CMakeLists.txt 8fd1dd0 
>   core/directoryprovider.h PRE-CREATION 
>   core/directoryprovider.cpp PRE-CREATION 
>   core/gluon_global.h.in 792d65e 
>   core/gluonobjectfactory.cpp 4501bed 
>   creator/plugins/docks/projectdock/projectdock.cpp e02ce53 
>   graphics/engine.cpp c4094b0 
>   graphics/examples/loadtexture/main.cpp 229f9a4 
>   player/kde/mainwindow.cpp 7071249 
>   player/lib/models/gameitemsmodel.cpp 63075ed 
>   player/lib/ocsprovider.cpp 1d5daa4 
>   player/qt/mainwindow.cpp 0470e33 
> 
> Diff: http://git.reviewboard.kde.org/r/101727/diff
> 
> 
> Testing
> -------
> 
> Overall Gluon's players seem to function properly. The userData function returns correct paths for me, request everyone to check once for their configuration.
> 
> 
> Thanks,
> 
> Shantanu Tushar
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/gluon/attachments/20110622/81131b81/attachment.htm 


More information about the Gluon mailing list