[Geany-devel] Multiple instances of Geany issues

[Lex Trotman]

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

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)

> 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.  By limiting save it to the main instances I was
hoping to reduce the surprise somewhat, but a better answer would be
welcome.

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