http://bugzilla.moblin.org/show_bug.cgi?id=8059
jku <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from jku <[email protected]> 2009-11-18 14:07:43 PST --- (In reply to comment #1) > Another proposal: > - if there is only one peer and that peer is to be removed, > also remove non-peer properties and nodes > - otherwise only remove the per-peer properties > > This has the advantage that it automatically removes the whole config context, > which might be what is expected when only dealing with one peer. The > disadvantage is that it removes the source settings even when the user of the > API might want to continue using them in his next peer configuration. > Because of this disadvantage I prefer a solution where per-peer views only > remove the peer properties and non-peer properties have to be removed > explicitly via a non-peer view. This sounds more reasonable to me as well. I'm trying to think through the use cases that the current UI design has (and the ones future changes have, as far as I can tell) and I think I don't need to modify non-peer source properties, I definitely don't want to remove them without explicitly saying so. Adding or modifying sources is of course in the realm of possibility for a UI, but currently I don't really have a good mental image of what this would include... I think I need to consult with you bit. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
