Bug#455527: unison-gtk: pressing "r" has different meaning
This is a not so intuitive, but designed feature of unison. Quoting v2.9.20's changelog: "Restarting update detection from the graphical UI will reload the current profile (which in particular will reset the -path preference, in case it has been narrowed by using the "Recheck unsynchronized items" command)." The 'r' key shortcut, which is equivalent to the 'restart' feature in the 'Synchronization' menu, triggers that behaviour. The really bizarre part is that the 'restart' button in the toolbar does not trigger that behaviour. --path' preferences are kept while roots are compared again. I plan to notify this upstream when the time is right (meaning: when they are done dealing with other submissions on my part). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351169: unison-gtk bug : 'r' shortcut does not behave as advertised
> From: Norman Ramsey [mailto:[EMAIL PROTECTED] > Sent: mercredi 14 mai 2008 03:21 > > > > From: Norman Ramsey [mailto:[EMAIL PROTECTED] > > > Sent: mercredi 23 avril 2008 18:51 > > > > > > You really don't want to see my profile definitions---my profile is > > > built dynamically depending on which pair of machines I'm > > > synchronizing and where they are located. But if you really want, > > > I'll send you a sample. > > > > What happens when you use a simple profile such as > > root = /tmp/root1 > > root = /tmp/root2 > > in default.prf, without any other prf files in ~/.unison ? Is the > behaviour > > reproducible then? > > I'm reluctant to make the experiment. > I've confirmed the misbehavior with unison version 2.27.57. > When I the hit 'r' key while focus is in the gtk user interface, I get > a dialog box, not the same function I get from the 'restart' button. > > > With your usual setup, does the same "root selection" dialog appear > when you > > use the "restart" feature from the "Synchronization menu"? (Please note > that > > the procedure called by this action is not the same as the one trigged > by > > the restart button on the toolbar, despite what their similar icons > suggest) > > Yes! I get asked what local directory I wish to synchronize. We're on to something here. Could it be that your particular setup not only dynamically generates the profile files, but passes -'path' parameters to unison-gtk on the command line? If this is the case, that's the explanation. > (Why is the action different, and what is the restart procedure from > the synchronization menu supposed to do?) Why 'restart' and 'restart' are mapped to different functions is an excellent question I plan to raise upstream. See http://bugs.debian.org/455527 > > Does this behaviour occur on all your systems, or only a subset? > > I have 7 computers in two different cities. The behavior occurs > everywhere I've had occasion to try it. That's at least three of the 7. > > > Norman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351169: unison-gtk bug : 'r' shortcut does not behave as advertised
And, after more careful thinking, does your setup add '-root' parameters to unison-gtk? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351169: unison-gtk bug : 'r' shortcut does not behave as advertised
tags 351169 - moreinfo - unreproducible + upstream merge 351169 455527 thanks > -Original Message- > From: Norman Ramsey [mailto:[EMAIL PROTECTED] > Sent: vendredi 16 mai 2008 23:33 > > We're on to something here. Could it be that your particular setup not only > > dynamically generates the profile files, but passes -'path' parameters to > > unison-gtk on the command line? If this is the case, that's the > > explanation. > > Yes! I use the -path option 100% of the time :-) > > > And, after more careful thinking, does your setup add '-root' > > parameters to unison-gtk? > > Yes. I never use unison-gtk directly; instead I have a rather complex > and scary wrapper. Partly this is because Unison scales very badly to > controlling 6 replicas with different requirements. I have had > lengthy conversations with Benjamin Pierce about better ways to handle > this problem, but Benjamin can't get any more 'research credit' for > work on Unison, and changes would be required to the part of the code > he fears most. A pity, but there it is. > I'm glad we solved this. > > Why 'restart' and 'restart' are mapped to different functions is an > > excellent question I plan to raise upstream. See > > http://bugs.debian.org/455527 > Perfect. Perhaps the two bugs should be merged? Right, the two do stem from the same counter-intuitive 'restart' feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351169:
tags 351169 - moreinfo - unreproducible + upstream merge 351169 455527 thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361198: Solved : another point of view
I experienced the exact same behaviour as Philip Frei. On my system, hal-device-manager was already installed. The installation of acpi-support-base made gnome-power-manager's hibernate feature work. The suspend function still triggered a "Suspend Problem - Your computer failed to suspend" error message. gnome-power-manager should probably depend on these two packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
