Status of kde-dev-utils

Luigi Toscano luigi.toscano at
Sun Feb 19 18:59:55 UTC 2017

David Faure ha scritto:
> 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]

Thank you for all the suggestions. I'm going to implement the above (aka:
remove the last 3 programs) with a meaningful commit message.
Apart from this change, any other comment before I merge the frameworks branch
into master?


More information about the release-team mailing list