Actually, I've looked at this. I don't understand the bug (and I can't reproduce it).
Given that the focus out event is used, it shouldn't be able to enter a loop. The pop up of the dialog doesn't itself cause a new (2nd) focus-out, because the widget is not focused again since the 1st focus-out. In fact, when I try this on my Linux machine with the aforementioned method to revoke write permissions, then I don't get this loop. After clicking away the dialog Geany becomes responsive as normal and only another focus-out event will re-trigger the save action. Since the dialog is modal, there is no way the widget can be become focused again (focus-in) which is, obviously, a requirement for subsequent focus-out event. For me, the theory, the code and actual behaviour all agree. Is this win32 specific, perhaps? Anyway, I thought about a possible (assuming the loop is really caused by the error popup): Since the 1st focus-out handler should be still running a flag could be set that no new save action is queued until that focus-out handler returns. That should make it impossible that the focus-out handler triggers itself. @rovf what are your exact save actions settings? I could imagine that instead of focus-out, the timeout save action is constantly triggering, for example if the timeout is low and the system takes longer than the timeout to find that it cannot write the file (again, perhaps win32 specific). IIUC g_timeout_add() preserves the interval regardless of how long the callback takes to execute (does somebody know this for sure?) --- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/815#issuecomment-165693298
