On Mi, 2011-01-12 at 07:34 +0000, Patrick Ohly wrote: > On Di, 2011-01-11 at 22:05 +0000, Frederik Elwert wrote: > > Am Dienstag, den 11.01.2011, 15:50 +0100 schrieb Patrick Ohly: > > > There's one catch here: the migration is supposed to be invisible to > > > such users. But as the code stands at the moment, the foobar.old config > > > will be visible to them. > > > > > > Two solutions: > > > 1. do not keep the backup config around > > > 2. filter out *.old in the list of configs reported via D-Bus > > > (which is what GUIs use); command line users will still see them > > > 3. name the automatically generated backups like something which is > > > more obviously not created by a user, like .foobar.old, and hide > > > that > > [...] > > Another idea: Create a dedicated directory for backups, e.g. > > ~/.config/syncevolution/.backups/, and move old configs there. Just a > > thought, don’t know if that has any advantages over the other options > > you mention. > > It has the disadvantage that the backup config is no longer accessible > at all inside SyncEvolution, not even to power users of the command > line. > > I still prefer option 2, but I'm only one user of SyncEvolution. I'm > vastly outnumbered.
I implemented a different solution, one which IMHO is more elegant than hiding *.old configs in the D-Bus call: in the renamed config, the ConsumerReady flag is reset to 0. That way the decision whether the migrated config is shown to users is left to the UI, instead of hard-coding it in the syncevo-dbus-server. The expectation is that a GUI for average users will hide both templates and existing configs unless they explicitly have ConsumerReady = 1. However, this is not exactly how the GTK sync-UI works at the moment. Jussi, do you remember why existing configs are exempt from the "ConsumerReady" check? We might have done it so that users can configure a non-supported server and then have it show up in the sync-ui, but then they might as well set ConsumerReady = 1 in the configuration. It would be consistent with templates. I suspect other GUIs also ignore it. I can update the GTK sync-ui. Frederik, would a similar change make sense and be possible in Genesis? -- 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
