D10078: Add separate lib KF5::DBusRunner

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D10078#253730 <https://phabricator.kde.org/D10078#253730>, @davidedmundson wrote:
  
  > > What do you think? Would give this a separate try tonight, to get some idea.
  >
  > Forwarding AbstractRunner::teardown is something I'd fully support.
  
  
  Forwarding `AbstractRunner::teardown` would be nice to have as well.
  
  Though I have been thinking of forwarding some (not yet existing) `RunnerContext::isValidChanged()` signal, once krunner has decided to no longer be interested in a context, due to query string having been changed by user,
  
  From my prototyping experiments I can tell that the current approach of recommending in API docs to discard-existing-request-if-new-one-arrived-as-we-assume-just-one-client-who-simply-upgraded-to-a-new-request feels incomplete/undecided. As implemtor I want to know which requests should be handled and which not.
  
  So a choice should be made:
  a) this should be codified as policy in KDBusRunner::AbstractRunner, to e.g. set any tracked existing MatchReply to invalid once a new request arrived,
  b) the concept of potentially parallel independent request should be officially supported (think e.g. stand-alone runner applets showing results in permanent non-popup list, updating automatically to some data source used as query string)
  
  In case b) it would be then good to have a way to tell which requests can be discarded and which should still get a full match reply.
  
  Actually I think we should hard-code a) for now, while at the same time leaving the option for b) once people start to have motivation to see b) supported.
  
  > At which point you don't need a signal in the context. IMO that's making things overly complex.
  > 
  > Note that the ThreadWeaver stuff in Krunner client is pretty messed up, so cancelling and whatnot doesn't really work as-is.
  
  Yes, the RunnerContext currently becomes suddenly invalid but without signalling to  the runner plugins when it happens, one has to actively query. But this could be fixed, given RunnerContext is a QObject.
  
  >> Using a QObject would also allow to switch from the fragile QVector<MatchReplyPrivate*> mActiveMatchReplies to using a QPointer-based approach on the real MatchReply objects, which might be less
  > 
  > You can use QWeakPointer already. I don't think it's particularly needed though.
  
  Did not know about QWeakPointer, might have a closer look if things could be implemented less fragile with it.
  
  Though making MatchReply a QObject for the mentioned purpose continues to make sense to me, even more now.

REPOSITORY
  R308 KRunner

BRANCH
  kdbusrunnerlib2

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/20180425/1f941ec5/attachment.html>