Re: patches on kcolors
On Thursday 08 March 2012 13:11:37 Giorgos Tsiapaliwkas wrote: This is my patch about moving kdialog to staging/kwidgets but I need to link to KGuiItem(KDialog requires that). I can do then job, but there was nobody in the channel to approve it. So I didn't. This KDialog move looks good. KGuiItem should move to kguiaddons I think. Which means moving KIcon and KIconLoader/KIconTheme too (KGuiItem depends on it). Right Steve? We said we would keep KIcon/KIconLoader -- kguiaddons ? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: patches on kcolors
On Thursday 08 March 2012 18:08:15 Stephen Kelly wrote:
David Faure wrote:
On Thursday 08 March 2012 13:11:37 Giorgos Tsiapaliwkas wrote:
This is my patch about moving kdialog to staging/kwidgets but I need to
link to
KGuiItem(KDialog requires that). I can do then job, but there was nobody
in the channel to approve it. So I didn't.
This KDialog move looks good.
KGuiItem should move to kguiaddons I think.
Which means moving KIcon and KIconLoader/KIconTheme too (KGuiItem depends
on it).
Right Steve? We said we would keep KIcon/KIconLoader -- kguiaddons ?
Well, considering that QIcon is in QWidgets, there's a widgets dependency
anyway.
Oh? It didn't land in QtGui after all? :-/
Is KGuiAddons supposed to be widgets-free?
That was the intent yes.
We did say we'd keep the KIcon{Loader,Engine,Theme} stuff, yes. Whether we
deprecate the KIcon class or replace it with methods in a namespace, I'm not
sure.
I'd be in favor of replacing it with factory methods in a namespace indeed.
That's really all there is to it.
Regards.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud patron of KDE, http://www.kdab.com
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: Monitoring autotest coverage in frameworks
Hi, Am 1. März 2012 00:44 schrieb Dario Freddi: I was wondering if we already had a way to generate reports on autotests coverage using lcov/gcov in frameworks. Looking at our cmake infrastructure, I spotted a build mode Profile which should apparently set the correct compiler flags (but actually, at least for me, it didn't work), I didn't go as far as seeing if it also forces every library to build static. Instead, there seems to be no mention of a lcov target. Question time: is anybody already working on this? I think it's quite important for us to have such a thing, and I'd be happy to provide patches for this to happen (would be cool if Alex or any other buildsystem gatekeeper gave a word about how this should be done/where should it go). it seems that measuring test coverage does work in kdelibs 4.x, at least there are results submitted daily to CDash: http://my.cdash.org/index.php?project=kdelibsdate=2012-03-01 AFAIK, the results which CTest gathers during the tests using gcov are written to an XML file (which is then submitted to CDash if you ran the tests using, e.g., 'make Experimental'). Best regards, Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
