hallas marked 3 inline comments as done. hallas added inline comments. INLINE COMMENTS
> dfaure wrote in klistopenfiles.cpp:49 > This reminds me of KCoreAddons' new KProcessInfo class, although that one > doesn't actually do this. > > I see that FreeBSD and OSX have lsof (and the man page doesn't say those > options are missing there) so it should be fine, everywhere except Windows. > > In general I don't really like starting executables like this, but indeed > writing a clone of lsof sounds like much work. I don't like starting executables either, it is slow, brittle and an implicit dependency - but I also think in this case it is the only feasible option :/ But is it ok not to support Windows? Or maybe the Windows implementation would emit a debug warning and then always emit an empty list? > dfaure wrote in klistopenfiles.h:40 > Reading the unittest, I definitely agree that a signal would be better. Then > you could use QSignalSpy::wait() without the need to use QEventLoop by hand > :-) > > This is really a job. I would inherit KJob for this, actually. It's the way > we do such things everywhere else. Thanks for the feedback! I will look into making a solution using a signal instead and push an updated commit. Regarding implementing this as a KJob subclass, do you have a good example of this? Would the result be delivered in a special signal, or is there a standard mechanism for this in KJob? REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D21760 To: hallas, davidedmundson, broulik, #frameworks, dfaure, bruns, #plasma Cc: cfeck, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
