Status of kde-dev-utils

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5