D21760: Add KListOpenFiles::listProcessesWithOpenFiles

[David Hallas]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190813/27f075fb/attachment-0001.html>