[Geany-devel] Multiple instances of Geany issues

[Eugene Arshinov]

On Tue, 1 Jun 2010 19:55:27 +0300%
Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:

> On Mon, 31 May 2010 13:35:26 +0400
> Eugene Arshinov <earshinov at 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.