On Thu, Oct 27, 2011 at 10:01 AM, Sebastian Kügler <se...@kde.org> wrote:
> On Friday, October 21, 2011 15:56:21 Reindl Harald wrote: > > having a css file on a test-server mounted via sshfs/smbfs and normally > > the tech-peopole like i making templates/css but after that changing a > > color-hexcode from the boss himself i guess is not so uncommon > > That doesn't work though, as file change notifications are not supported > across all KIO slaves, I'm sure they don't work for fish://, haven't tried > Samba, but I'd advise against relying on this behaviour. > > Regardless, as others have pointed out already: This is really a fringe > case. > While we should make it possible, it would be daft to base the default > behaviour on that, and not on what's the usual situation when this case > arises. > > A sensible solution to me would be to warn with a passive popup that the > file > has been automatically reloaded and offer an option to undo the automatic > reload. > I'd make the case that if externally created updates are so rare and are a distinct exception from normal expectations then the notifications for them should be as big and noisy as possible. Given the rarity and the potential harm from not addressing the issue, interrupting the user and making them address the situation directly seems to me like the sane default. Perhaps at that point the options to do some behavior by default could be set. I don't even see how you could choose a sane default behavior in absence of context; 'overwrite by default' might make sense if you have a log file open but 'keep my version' or 'merge my changes' or 'show a diff' would make more sense if you've been editing a source file for 3 hours that is then accidentally touched by someone else.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
