Hello! SyncEvolution supports X-EVOLUTION-UI-SLOT, a parameter for TEL/EMAIL/X-AIM/... which specifies in which slot of the GUI the corresponding value is to be displayed. That's useful because there's a fixed number of slots but an unlimited number of values, plus the order is also something that the user might want to tweak.
I just discovered that Nokia phones get confused by this parameter in an... interesting way. Sending a new VCARD with X-EVOLUTION-UI-SLOT isn't a problem, but sending an update with it causes the phone to remove all TEL/EMAIL properties (even if unchanged) - http://bugs.meego.com/show_bug.cgi?id=2566 We already discussed before that declaring this parameter in CTCap causes the phone to not send EMAIL/TEL to us (http://bugzilla.moblin.org/show_bug.cgi?id=8868). Because CTCap has to be available before knowing who we talk to, the solution was to not show X-EVOLUTION-UI-SLOT (show="no" in the config). Now I would go one step further and suppress generating this parameter for a peer, after identifying the peer. I thought that this should be possible with the remoterule config option, but <parameter> doesn't support that according to the documentation. BTW, the config parser doesn't complain when it is specified, it just doesn't do anything. Is adding support for it a good idea? The semantic would be "during parsing and generating, ignore parameter unless no remoterule set or rule is active". I'm a bit uncertain whether this should apply during parsing *and* generating, because parsing something that was sent to us shouldn't do any harm. But it wouldn't be consistent. Can someone give me some pointers into the source code for adding this? One more question about the commit which introduced the concept of multiple active rules (3627eb1cf5e48981f56940f2f2c292e6c253d5d3). Currently, TMimeDirProfileHandler::fActiveRemoteRules can only be set such that it contains multiple rules via the config parser, right? void TMimeDirProfileHandler::getOptionsFromDatastore(void) { ... fActiveRemoteRules = fRelatedDatastoreP->getSession()->fActiveRemoteRules; // copy the list ... } TMimeDirProfileHandler::setRemoteRule() wipes out the list before adding one entry. As a result, the PARSE/MAKETEXTWITHPROFILE() macros can only be run with one active rule, because that rule is set with setRemoteRule(). In the solution that I have in mind, enabling the X-EVOLUTION-UI-SLOT would be done like this: <subrule name="HAVE-EVOLUTION-UI-SLOT"> <!-- parameter X-EVOLUTION-UI-SLOT is not generated by default, must be enabled for peers which support it --> </subrule> <remoterule name="SyncEvolution"> <manufacturer>Patrick Ohly</manufacturer> <model>SyncEvolution</model> <include rule="HAVE-EVOLUTION-UI-SLOT"/> </remoterule> <remoterule name="EVOLUTION"> <deviceid>none - this rule is activated via its name in MAKE/PARSETEXTWITHPROFILE() macro calls</deviceid> <include rule="HAVE-EVOLUTION-UI-SLOT"/> </remoterule> MAKETEXTWITHPROFILE(... "EVOLUTION") Except that the last step doesn't work yet either. Would it make sense to extend TMimeDirProfileHandler::setRemoteRule() such that setting a rule also sets all included rules? Or should isActiveRule() do a recursive check? Both depends on TRemoteRuleConfig containing a list of the <include> rules, something I that haven't checked. -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
