On 08/03/2010 08:41 PM, Ivan Čukić wrote:
> I know you're going to hate me, but I have to - recent documents in
> the app should be restricted to the activity as well.
> Would it work if the term provided would be ResTerm('activity') &&
> ResTerm('application')Currently this Comparison( xxx, ResTerm(a) && ResTerm(b) ) would result in a broken query. I could add support for that in the standardQuery call though. But then again what did we decide? Will the activity be linked to the graph or the event? I think it was the former in which case we need two different terms anyway which means we could use the approach of combining standard queries like so: standardQuery( ResourcesForActivityQuery, ResourceTerm(activity) ) && standardQuery( ResourcesForApplicationQuery, ResourceTerm(app) ) && standardQuery( MostImportantResourcesQuery ) > IMO, the enum approach provides versatility on one level, but can be > rather restricting if we don't cover most of the use-cases at the > beginning. how so? and which approach is better? Adding dedicated methods for all cases has no advantage since that can be done at any point in time once we reach the boundaries of the enum approach. But if you don't like the enum - we can also use dedicated methods. I just think a combination to keep the number of methods small makes sense. >> And I also added a hint as to how standard queries can be combined to > > I didn't see the hint here it is in the docs for standardQuery. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
