kossebau added a comment.
In D10078#253982 <https://phabricator.kde.org/D10078#253982>, @davidedmundson wrote: > > 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 > > Not really. It leaves it up to the implementor. It covers the simple case well, and any advanced case is still do-able quite easily. ? As implementor, I can report you first hand: I want to know whether it makes sense to continue handling a MatchReply or if not. As in: what is the minimum I need to do to correctly and completely serve the requests. Having an API which has me doing potentially useless stuff because it does not tell me whether something is useful to do or not, would we not call this a broken API? > Adding QObjects in context doesn't make sense. If you're processing stuff you won't process the signal. If you're not processing things then you don't need the signal. Well, it makes sense once you process things in other threads with event loops due to further async processing, no? REPOSITORY R308 KRunner BRANCH kdbusrunnerlib2 REVISION DETAIL https://phabricator.kde.org/D10078 To: kossebau, broulik, davidedmundson Cc: bruns, michaelh, ngraham, #frameworks
