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