On Thu, 2009-06-25 at 08:52 -0700, Lukas Zeller wrote: > Hi Patrick, > > On Jun 25, 2009, at 17:05 , Patrick Ohly wrote: > > > I considered this "remote rule" feature rather important for today's > > SyncEvolution snapshot, therefore I already went ahead and merged it > > into the "master" branches of SyncEvolution and libsynthesis on > > moblin.org. > > I just pulled from the remote-rules branch you created in indefero. I > assume the patches are the same?
Better pull "master" from moblin.org. I didn't mean to push into indefero and the copy there might be older. Hmm, I'm trying to use the new expat header check and it fails on Moblin. HAVE_EXPAT is not set although it should. Better hold of merging this. > On Jun 23, 2009, at 22:55 , Patrick Ohly wrote: > > > Is there a better way that avoids the dummy property entry? > > > > What about adding support for: > > <property name="X-MANAGER" suppressempty="yes" > > rule="^EVOLUTION"> > > <value field="MANAGER" show="yes"/> > > </property> > > Could be done, only I'd suggest "!" for the NOT char. Right, it should be a logical NOT. > > The drawback is that multiple not clauses are impossible, > > You are referring to the case where you'd have 2 or more remote rules > (say: A,B,C) and would need to express NOT A AND NOT B AND NOT C? Yes. > On a second thought, I think the negation is not necessary. Just > insert a catch-all rule at the beginning of the remote rule list with > only <finalrule>no</finalrule> in it. Then you can relate the X- > MANAGER to this rule instead of needing a NOT. Sorry, I don't follow here. Can you give an example? However, I don't think it would help: the remote rule is activate in the macros via its name. The content of the rule (finalrule, suppressempty, ID, ...) is completely ignored. I wanted to use suppressempty as default when generating items for Evolution, but because the profile handler only copies those settings if a related datastore is given. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
