Re: kemoticons is now in staging
On 2012-11-19, David Faure faure+bluesyst...@kde.org wrote: Let me say this differently: look at the huge mass of code in Qt: almost none of it uses QSettings to let the users configure things from underneath. Most of the time, the apps themselves have control over the various settings offered by the Qt API. The exception is the stuff available in `qtconfig`, but that's quite limited. So maybe this setting should be left to the application, if that makes sense. I was actually going to do a mail suggesting the same. /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kemoticons is now in staging
On Tuesday 20 November 2012 23:03:50 Valentin Rusu wrote: * Is the dependency on KService really needed? Or QStandardPaths would be enough? kemoticons uses backend plugins. So it's not simply about QStandardPaths here. Sure, sorry if I was unclear. KService vs QStandardPaths is about locating the plugins part, for loading them you need some extra calls and that's KPluginLoader vs QPluginLoader. We should take the decision on how we locate the plugins though, hence why I pointed out QStandardPaths. In other words: Does kemoticons really need the querying system of KService? Or looking into a set of known folders to find the plugins would be enough? However, I think that the way I had to add the dependencies on kservice is somewhat ugly, as it requires 4 lignes in order to get kservice headers compiled when included from this framework. Is there any new KF5 macro to add kservice inclusions in a single line? You did it in the proper way for now. It'll get cleaner when kservice moves to its final place. * The only reason it depends on KConfig is to take a look in kdeglobals, we might want to do that differently (QSettings could be a contender?) I'll check that. Make sure to check the emails from David and Sune as well on that topic. They're right that QSettings is likely not needed, and that it should/could be something controlled by a symlink like the icon themes, or a similar mean. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kemoticons is now in staging
Hello, On Thursday 08 November 2012 20:28:59 Valentin Rusu wrote: I Just wanted you to know that I just pushed the kemoticons relocation to /staging. I know I'm pushing people away from kdelibs splitting ATM, but that one should be independent enough from the rest that splitting it should be doable, it's kind of an exception. All the code compiles, but I have not yet managed to run the included tests. I'll carry on to check all the TODO items and announce here when I'll think all was done. OK, thanks for tackling that one and keeping up posted on your progress. I took a quick look at the current situation. Questions you might want to investigate (in no particular order): * Do you really need dependency on kwidgets/src/icons? I might have missed it but I didn't find kicon* inclusion. * Is the dependency on KService really needed? Or QStandardPaths would be enough? * The only reason it depends on KConfig is to take a look in kdeglobals, we might want to do that differently (QSettings could be a contender?) * You might want to have two subdirs under src, one for the lib itself and one for the provider plugins. That's all the ideas I got so far, I assume you'd welcome some food for thought. ;-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
