[Geany-devel] Multiple instances of Geany issues

[Eugene Arshinov]

On Wed, 2 Jun 2010 18:10:26 +1000%
Lex Trotman <elextr at gmail.com> wrote:

> On 2 June 2010 17:19, Eugene Arshinov <earshinov at gmail.com> wrote:
> > 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.
> 
> Good idea, if Ditmar can say how his works against the points, I'll
> fill in trunk versions properly tomorrow, but quick look says:
> 
> trunk: not 1, 2 is irrelevant (no sm), 3, 4, not 5 and can corrupt but
> took opening multiple instances in a script for it to happen, not 6
> (stores on all project opens)
> patches, I think do: 1 without warning or reload, 2 still irrelevant,
> 3, 4, 5 I'm not sure, 6 without preference, I need to check where we
> ended up re main vs new-instance and what they saved.
> 
> >
> > 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 :)
> >
> 
> I'm confused, how does the session restore if you don't save each
> instance file list, current project etc.?
> 

My SM works by specifying restart command, where I can specify any
command-line arguments.  Opened project, files, and some settings
(--new-instance, --no-session etc.) are passed this way.

> And as multi screen workstations are more common among developers,
> running multiple instances is the only way to get Geany on both
> screens, and they are likely to want the same project, thats what the
> user is working on after all.  I agree less likely to be two main
> instances, but main and --new-instance is very likely, I'm planning to
> use it a lot to look at C++ .hpp and .cpp files at the same time.
> 
> AT least until Geany can show multiple top level windows. :-) (I know,
> someone has to do it)
> 

Multiscreen is a good argument.  Never thought about it, because I've
never had several monitors :)

> > 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?).
> 
> Sorry if I wasn't clear enough, I was talking about Geany saving the
> current file list in the *config* file when a project is opened, not
> about the project file, when another instance closes its project, it
> restores the file list saved in the config by the instance that last
> *opened* a project.

Thanks, now it's more clear, but I'm still confused.  Could you further
explain the last phrase "when another instance closes its project, it
restores the file list saved in the config by the instance that last
*opened* a project"?  Why do we need such complexity (we must know
whether the instance which was the last to write the file list to the
config opened the project before or after us…)?  Why can't we let the
last instance overwrite the file list completely?

>
> By limiting save it to the main instances I was
> hoping to reduce the surprise somewhat, but a better answer would be
> welcome.
> 

Well, in SM the file list and the recent project in the config are
indeed saved only by main instances.  Secondary instances are not
allowed to touch them (being more concrete, in SM --new-instance
implies --no-session).

> >
> >> 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.
> 
> Ok, as I said don't care except for the overhead.
> 
> 
> Cheers
> Lex
> >
> > Best regards,
> > Eugene.
> > _______________________________________________
> > Geany-devel mailing list
> > Geany-devel at uvena.de
> > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
> >
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel