On Mo, 2011-01-17 at 19:29 +0000, Frederik Elwert wrote: > Am Montag, den 17.01.2011, 20:07 +0100 schrieb Patrick Ohly: > > On Mo, 2011-01-17 at 16:19 +0000, Frederik Elwert wrote: > > > I think your suggestion makes sense. I always understood ConsumerReady > > > to only make sense in a template context, that’s why I currently don’t > > > handle it in Genesis. But using it to hide unwanted configs seems to be > > > a smart idea. > > > > > > My only issue with it is that it isn’t backwards compatible. So if I > > > implement what you suggest, configs that were created based on > > > non-supported templates with the current sync-ui won’t show up in > > > Genesis any longer. So I feel I should at least wait until the next > > > SyncEvolution release which explicitly sets ConsumerReady = 1, so > > > re-editing the config in sync-ui would make it show up in Genesis again. > > > > Nothing in SyncEvolution will magically set that flag. Or rather, I > > wasn't planning to. Now that you mention it, I might as well set the > > flag for any migrated configuration from SyncEvolution < 1.2, because > > these used to be user-visible. > > Maybe I wasn’t clear. I meant that sync-ui in SyncEvolution 1.2 will set > ConsumerReady = 1 when one creates/edits a config, even if it is based > on an unsupported template. Or did I get that wrong?
The sync-ui already wouldn't show configs without the flag, so they cannot be edited. > Then, editing a > config in sync-ui would be enough to make it visible again in Genesis’ > config list. But however, doing so on migration might prevent the > problem at all. ;-) Indeed. Except that they won't be migrated unless the user sees and uses them, which he won't - darn. How about this: syncevo-dbus-server transparently adds the flag to existing, old-style configs. Then both sync-ui and Genesis will see the flag, as before, despite the additional check in the UIs. In addition, migrating the config sets the flag permanently. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
