Am Montag, den 17.01.2011, 20:44 +0100 schrieb Patrick Ohly: 
> 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.

Ah, yes, I missed that.

> > 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.

That sounds reasonable to me.

Regards,
Frederik



_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to