> one thing i'm not a fan of with the new Consumer approach is that it is > impossible to know whether the code will block or not. it does a pre-fetch > and then cleverly blocks only if it hasn't received a reply yet. which > means there is no way to guarantee async behaviour when desired. as long as > the calls to kactivitymanagerd are blazingly fast (and/or Consumer is > always created in sufficiently in advance of usage) this is a minor issue.
Without the blocking. the hell would break loose - it wouldn't be backwards compatible and every kactivities client would need to be patched. > > or remove it since we IIRC don't use it in any important place. > but we want to, right? Not really. The method that only gets a list and doesn't notify you on changes and similar is not that useful in my opinion. We need data models for it (currently, this specific case is covered by Nepomuk::Query that is used in PA) Ch! -- You know, there are many people in the country today who, through no fault of their own, are sane. Some of them were born sane. Some of them became sane later in their lives... -- Monty Python's Flying Circus
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
