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
