On Tue, 1 Jun 2010 19:55:27 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 31 May 2010 13:35:26 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Just to mention, I ported to my SM branch the patches posted earlier in this thread.
Also, I've changed the code to write changed recent files and projects lists to geany.conf as soon as possible instead of writing them on exit. [...]
I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session, without as much as a xfce sm signal to the applications. The only error message I was able to record is "ICE default IO error handler doing an exit(), pid = 8983, errno = 32". The pid is Geany's.
It is terrible… I'm not experiencing this here in GNOME. Could you check previous revisions to determine when the bug appeared?
After this one problem remains: handling of a project opened in several instances. It could be easy to apply "immediate save" technique for them too if we hadn't to maintain list of project's files.
Currently, both the project settings and files are saved on any of Project -> Preferences, Project -> Close / New / Open and File -> Quit.
Following the logic of the other patches, IMHO Project -> Preferences should save the settings only, and the other functions should save the file list only.
Yes, precisely.
As of a project open 2+ times, I expect the file list to be almost identical. It's not like running a -i instance, which starts with an empty file list.
How should lists of files from several instances be combined?
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else.
Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice…
Best regards, Eugene.