[Geany-devel] Multiple instances of Geany issues

[Eugene Arshinov]

On Wed, 2 Jun 2010 12:14:48 +1000%
Lex Trotman <elextr at gmail.com> wrote:

> <snip>
> 
> >> 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…
> 
> Hi all,
> 
> Having gotten confused where each of the implementations is up to I
> want to summarise the overall operation.
> 
> The same problem applies to three types of files, the config file
> (geany.conf), the project file and (possibly several) filetype files.
> 
> BTW changing filetype files is not that rare, every time you add an
> option to your compile command you change one.  Me, I add/remove -g
> quite often :)
> 
> Actions performed by the user are fine because they serialise them, ie
> users can only do one thing at a time, problems only occur on multi
> instance session close and restart.
> 
> I can summarise what is for me, the only correct answer (after a LOT
> of discussion, thanks for the patience Ditmar & Eugene):
> 
> 1. save the config/project/filetype file settings when changed, in any
> instance but with warning in non-main instances, no race because user
> serialises, last changed wins (see !! below), add reload menu item(s)
> to allow user to sync instances if desired
> 2. When closed by sm, save the file list in a per instance session
> file not the config/project file, then when the session is restarted
> each instance loads its session file list not the config/project file
> list and doesn't store in project or config file, no race
> 3. when closed by user, save the file list in the config/project file
> as normal, no race because user serialises closing, last wins (easily
> understandable)
> 4. when SIGHUPed, ie non-session multiple shutdown, save nothing
> (current behaviour)
> 5. when project loaded in non-main instance do not store current file
> list in config file, no race, and won't overwrite main instance list
> with an empty one
> 6. when project loaded in main instance (by user not by sm) store the
> current file list in config file, last main instance opening project
> wins, no race because user serialises
> 
> (!!) Note item 1. currently all preferences are saved, lots more work
> but better, would be to only save those items changed so a sort of
> merge would happen instead of total overwrite, maybe this could be a
> later version.
> 
> I think that covers it.  No races, maximum flexibility with warnings
> for non-main instance changes and good restoration of the current
> session on restart.
> 

Great summary.  Now what we need is a comparison table with four
columns for trunk, trunk with your and Dimitar's patches, my SM
and Dimitar's SM.

At first glance, seems that my SM implements 1 (but without warnings
and possibility of reload), 3, 4, 5, and the first half of 6.

It does not implement 2, and I do not consider it a severe issue.  I
believe a "normal" user rarely opens one project in two instances or
runs several main instances using --socket command line options. If he
doesn't, there won't be any race.  Even with my SM implementation :)

The second half of 6 ("last main instance opening project wins") seems
somewhat strange to me:
* Shouldn't it also hold for secondary instances?  I think we shouldn't
  differentiate the behaviour of main and secondary instances in
  respect to handling of project files.
* I'd prefer "last closing wins", not "last opening wins" (the way we
  usually implement things, isn't it?).

> I admit I don't use recent file list much so my choice is for the
> easiest :). So I agree, I wouldn't bother merging recent list.  Since
> its in the same file(s) as the file list just let it work as the file
> list does in 1-6.
> 
> If enough users of the feature want it to merge, make it append to
> whats in the config/project file every time a file is opened/closed by
> user (ie act like a preference in 1. above).  I'd prefer to not have
> this much traffic on the config/project file though, so by preference
> only.
>

Just for clarity, this is how recent lists are now handled in SM,
except that the preference is not provided.

Best regards,
Eugene.