[Geany-devel] Multiple instances of Geany issues

[Lex Trotman]

<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.

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.

Cheers
Lex

>
> Best regards,
> Eugene.
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>