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=kdelibs&date=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
Re: KAction to QT migration plan
On Mon, Feb 27, 2012 at 10:40 PM, Kevin Ottens wrote: > Hello, > > So here are my 0.02€. > > On Sunday 26 February 2012 12:56:33 Valentin Rusu wrote: >> As previously discussed here, I prepared a migration plan for KAction >> class. It takes the form af a spreadsheet available here: >> https://docs.google.com/spreadsheet/ccc?key=0Aj05Q1-vupr3dFFoUUYyc2pTZlltUFd >> RX3M5Z1Y2aGc >> >> After doing this, I think that further discussion is needed to decide >> some issues. >> The more important issue is: should KGlobalAccel go to Qt? >> >> More details on this: >> - KGlobalAccel communicates with kglobalaccel KDED, >> - if KGlobalAccel goes to Qt, then the KDED module should also go, in my >> opinion. >> - if KGlobalAccel goes to Qt, then KAction class will only hold KAuth >> specifi code. > > The problem I see there is that there's no chance for KGlobalAccel kded module > to go in Qt. There's no Qt equivalent to kded in the first place. > >> This brings second issue : should KAuth go to Qt? >> From the actual kdelibs state I understand that "no". > > That's correct, kauth is here to stay as an independent part. > >> So KAction class will not dissapear as it'll have at least the KAuth >> specific code. > > Well, from the approach you apparently followed that's the only conclusion > possible indeed. If you think in terms of "pick a method from KAction and move > it in QAction" there will always be left overs. So I think it should partly be > approached from a different angle: > a) Which features from KAction makes sense for Qt in general? > b) From the left overs, how can we make a different API for them? > > Regarding (a), I tend to think only the support for default shortcuts make > sense, it's definitely missing from Qt to handle action settings properly. And > if it fails to put that part in Qt then we'd treat it in the (b) case. > > Now for (b), it seems that most of the cases are of the type "attach some bit > of information to an action that is then consumed at some other place". It's > not like any of the KAction specific properties add behavior, so I'm thinking > that maybe instead we should change to an API where we register the actions to > their consumption point. For instance, for the gestures support, instead of > having a setShapeGesture method on a KAction, we'd have a gesture manager on > which you can register an action for a given gesture... now looking at KAction > code it's exactly what's done internally, we just register the action to a > KGestureMap singleton. Solution could just be to improve this KGestureMap API > in this case. > > So mostly food for thought here. Hope that helps a bit nonetheless. > > Regards. > -- > Kévin Ottens, http://ervin.ipsquad.net I have been thinking for a long time now that kglobalaccel needs to be reworked. Its current restriction to just keyboard shortcuts and its lack of extensibility seems too limiting. I think a better approach would be to have it act as an intermediary, where plug-ins would send it events, and it would then map these events to actions. So, for example, the keyboard button or gesture handler would both just feed events to kglobalaccel. So could a mouse button handler (Qt5 will have support for extra mouse buttons), kremotecontrol, even simon. This would require some major changes and a public api (or dbus?), but I think it would bring the shortcut system in line with the rest of kde in terms of flexibility and extensibility. -Todd ___ 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: patches on kcolors
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. Is KGuiAddons supposed to be widgets-free?
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.
Thanks,
Steve.
___
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 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
