kossebau added a comment.
In D10078#252871 <https://phabricator.kde.org/D10078#252871>, @davidedmundson wrote: > This makes it quite easy for a developer to screw up and block krunner. > The RAII approach makes it very very hard for a developer to screw up with any of the multiple usage patterns. Seems we have two different main design motives then: mine was to keep the classes/concepts close to the in-process krunner plugin ones, yours is to try to lower the chance of blocked calls :) Guess I am not so burned by blocked krunner plugins to give that so much weight, as I also do not see the danger of people forgetting to do any finishMatching call. And would argue that the D-Bus Krunner.side proxy should protect itself in general against remote D-Bus krunner services locking themselves up in other ways. Your project, your call/decision :) I propose two renames though: 1. class "*Context" -> "MatchReply" (or similar/better): the "*Context" class in normal in-process krunner plugins has a different, passive purpose, also might "submit/cancel a context" not make that much sense? (non-native speaker here, might miss out phrase meanings) 2. request handling method name "startMatching" -> "handleMatchRequest"(or similar/better): for a method "start*" I would expect some counterpart methods on the same class/object. I could not remember a Qt/KF class following the same pattern (something like single-thread service class with a handler method to do async request replies), so no existing naming pattern handy for proposal. At least I imagine that as developer having to reimplement virtual void handleMatchRequest(const MatchReply::Ptr &matchReply); one has a better idea about what to do, compared to virtual void startMatching(const RunnerContext::Ptr &context); Even if the mixing of request properties (query string) into the reply class spoils the concepts a little. But splitting that off into another separate object makes the code more complex again, so that trade-off could be fine. REPOSITORY R308 KRunner REVISION DETAIL https://phabricator.kde.org/D10078 To: kossebau, broulik, davidedmundson Cc: bruns, michaelh, ngraham, #frameworks
