On jeudi 16 février 2017 23:57:37 CET Luigi Toscano wrote: > Hi all, > I started the porting of kde-dev-utils to Frameworks. It was a educative > experience and I learned a lot (especially cleaning up oooold code), now I > have the question about two components. But let's me summarize the status, > starting from the more stable bits: > > *kuiviewer* > Ported, no KDELibs4Support, apparently on par with the old version. > > *kpartloader* > Ported, no KDELibs4Support, apparently on par with the old version (and > useful to find which KParts misses the translation domain, for example)
Cool. > *kprofilemethod* > A simple header with two macros which should be added to the code to get the > timing using QTime. Blindly ported, not tried yet. Well, that's interesting. I wrote it in 2002, and completely forgot about it since. I doubt anyone else has ever used it. I'd say kill it. I would actually need something similar right now, but for library code the "call this macro at the end of the program" isn't convenient. This should be written with a global object's destructor. And QElapsedTimer. And C++11 :) > *kstartperf* > blind port, not working currently (no performance measured), wondering > whether to investigate the magic that it does reading X properties or > forget about it in favour of KCacheGrind It can't possibly work, it's redirecting X11 calls (such as XMapWindow), while Qt5 uses XCB now. I'd say kill it. > *kmtrace* > It should debug malloc when GNU glibc is used, but: > - it still has Q3Support; I blindly applied the Frameworks porting scripts, > but of course it can't be compiled so far > - I can't even check the behavior of the kdelibs4 version because it seems > to run forever even on a small log generated by the tracing part. Milian's heaptrack [1] is a thousand light-years ahead of this. Kill it. [1] https://cgit.kde.org/heaptrack.git -- David Faure, [email protected], http://www.davidfaure.fr Working on KDE Frameworks 5
