On Fri, 21 May 2010 22:05:10 +1000 Lex Trotman elextr@gmail.com wrote:
On 21 May 2010 20:06, Dimitar Zhekov hamster@mbox.contact.bg wrote:
The way it can be implemented in detail (since I fubmled with the respective files in the last few days): [...]
Yeah, save_dialog_prefs would need the parts of configuration_save() that opens and closes the file of course :-)
[...]
Yes.
OK then, I'll write a patch for 4934.
If this is applied to the projects, it would be something like: [...]
I'm afraid I didn't think this through enough, any change to a setting will update the project file and get it a new timestamp so you would be getting the message all the time.
Edit -> Preferences will be saving only the main dialog preferences now, so that will be less common.
I guess that if we allow multiple openings of the same project (and I can't see how we can prevent it) then when a setting is changed it will change the project file. Its probably not really a problem, it was the race when multiple instances closed that was the problem.
Isn't the "race" (as in broken file because 2+ instances write it at once) only a problem of the original SM implementation? I mean, a user can't close two projects or two Geany-s _that_ fast?..
- Closing a project or quitting Geany saves only the file list, and
only if that's a main instance.
Hmmm... Now did I assumed that a project is first open in a main instance?.. Or that it's open in any main instance at all? If I open foo.geany in main and bar.geany in secondary instance, bar's files will never be saved? Clearly a no-go.
Yes this will remove the race for the project file on closing multiple instances.
Socket-based main/secondary instances can't a fix race. In post-0.18 you can specify a socket name and have several "main" instances. The geany.conf patch will help with improper manual close order, not racing.
Also I've just discovered that if I close a new_instance with files open when the main instance has a project open, on closing the project, the main instance's session matches the session files that were open in the new_instance.
Clearly the main instance is re-reading the conf file and getting the session files written by the new_instance. Saving session files only in the main instance will fix this too.
Exactly the "improper manual close order", the patch should fix it.