[Geany-devel] Multiple instances of Geany issues

[Lex Trotman]

On 3 June 2010 01:08, Eugene Arshinov <earshinov at gmail.com> wrote:
> 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.
>

I see, I assume that those commands are stored by the session manager

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

As you get older your font gets bigger and you need more real estate :)

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

This isn't added complexity, its just how it works now, if sm changes
that then I didn't notice, sorry.

Let me give example sequences:

How it works with a single instance:

open Geany, open several files, open project, Geany saves the list of
several files in Geany.conf and opens the project file list, close
project (which can be after several opens and closes of Geany) saves
list of open files in project file and close them and then open the
files listed in Geany.conf Perfect!!

How it works with several instances (numbered):

open Geany1, open several files1, open project1 Geany1 saves list of
files1 in Geany.conf and opens the project1 file list, open
--new-instance Geany2, open some files2, open project2, Geany2 saves
the file list2 in Geany.conf overwriting file list1, close project1,
Geany 1 saves project1 file list and opens file list2!!! it reads from
Geany.conf, confused grumpy user :(

or if --new-instance versions are not allowed to save file list, how
do they restore the open files when the project is closed?

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

Which raises the second problem noted above.

I don't claim to have a good solution for this one, I just want to get
the solution with most user utility and least user surprise.

Cheers
Lex

>
>> >
>> >> 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
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>