D10078: Add separate lib KF5::DBusRunner

[Friedrich W. H. Kossebau]

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