[Geany-devel] Multiple instances of Geany issues

[Lex Trotman]

On 21 May 2010 15:13, Eugene Arshinov <earshinov at gmail.com> wrote:

> On Fri, 21 May 2010 14:34:36 +1000%
> Lex Trotman <elextr at gmail.com> wrote:
>
> > Hi All,
> >
> > I've created this thread separate from Eugene's and Ditmar's session
> > management threads because my concern is mostly about other parts of
> > Geany and I don't want to be seen as criticising either of them as it
> > was their input that started me thinking.
> >
>
> New thread is a good idea.  I am tired of looking up for recent
> messages in that large "Race condition" thread I created :-)
>
> > Having multiple Geany instances is a great capability,
> >
> > *  I can have two (or more) projects open to share code or to
> > interrupt work on one to do something an another,
> > *  I can have Geany on *both* of my screens so I can see different
> > parts of what I'm working on
> > *  I can set up my filemanager to open different instances so opening
> > random files won't affect the work I'm doing
> >
> > My concern is that we should make sure that the way Geany works is
> > safe and preferably causes no surprises when multiple instances are
> > sharing files.
> >
> > There are three types of files that Geany instances could share and I
> > think they should be handled differently:
> >
> > *  Files being edited (the second of my use cases above).  I don't
> > think it is up to Geany to handle users editing the same file in
> > multiple instances, its up to the user to sort it out when time comes
> > to save.  A user can always set readonly to protect against
> > themselves.  Making --readonly a command line option would be a good
> > addition.
> >
> > * Project files (same project in two instances), since the user
> > doesn't explicitly control the project file I think Geany is going to
> > have to become involved in this case.  The only options that I can
> > see in this case are:
> >
> > **  when a project file has changed on disk (by date/time), for Geany
> > to ask if it should save or save as or throw away any changes to
> > project from this instance.  This way an instance won't silently
> > overwrite changes made by another instance, and with save as I can
> > procrastinate by saving this instances changes elsewhere until I can
> > decide which I want.
> >
> > ** only the Geany not started with --new-instance can save the
> > project file
> >
>
> The second option seems strange to me.  Practically, it will forbid
> opening two projects simultaneously so that they are both saved. Or do
> I miss something?
>

Nope, I didn't say it was a good solution :-) or necessarily the final
solution but it could be done before 0.19.


>
> Also, I can't see the point in opening one project in two instances…
> So, as to me, it isn't worth writing any code to handle that.
>
>
To get two windows with the same configuration.  My particular area is the
build config, but more and more prefs are getting overridden in the project
file like long line was recently etc.

Leaving a known potential problem situation in the release is IMHO bad, even
if we think its likely to be rare.  Its particularly bad if I get bit by it
:-)


> > *  Geany.conf (shared by any two or more instances), this is a real
> > potential problem if multiple instances try to save the same file.
> > Discussions in another thread seemed to come to the conclusion that
> > only the Geany that was started without --new-instance should save it
> > preventing races when several instances are closed at once.  BUT this
> > is not implemented in the SVN that is about to become 0.19 and in my
> > test a new instance overwrote the main Geany.conf losing session,
> > recent files etc!!!
> >
> > I think that preventing --new-instance from saving project and
> > preference files should be implemented before 0.19 is released
> > otherwise failing to close instances in the right order or missing an
> > instance when logging out will overwrite the preferences.  And
> > configuring a filemanager to use --new-instance will overwrite when
> > closed even if no other Geany is running.
> >
>
> Well, actually there is a very simple solution -- just check if we are
> run with --new-instance in `configuration_save' and forbid saving
> anything in this case.  This is what I committed to SM.
>

I thought you had but I couldn't find it in "the big thread"  :-) can you
extract that as a patch against SVN?


>
> But now there is a suggestion from Dimitar to also support changing
> preferences in secondary instances.  The last solution I wrote in "the
> large thread" is to change automatic saving when closing.  It should
> save only things that are not related to Preferences dialog (window
> position, opened files if needed etc.), and only in the main instance,
> of course.  Changed preferences are saved immediately after applying
> changes user made in the Preferences dialog, either in a main instance
> or a secondary instance.
>
>
Have to think carefully about which things are in which category, maybe it
could be ok, and could be applied to the project files as well.  Reload
would be good as well so that settings can be transferred between instances.


> As to me, I don't need to be able to change prefs in secondary
> instances as I always have main instance running.  But this feature
> might be useful to other Geany users…
>

Sure.


>
> > Later on we can look at the other options and also look at indicating
> > to the user which Geany instances can save, maybe by something after
> > the Geany in the title bar?
> >
>
> As to me, the title is already "overcrowded" (for example, just now I
> have "notes.html - /home/eugene - [home] - Geany"). Instead, I would
> like to see this indication in the status bar.
>

Sure, fine by me.

Cheers
Lex

>
> Best regards,
> Eugene.
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20100521/0b7c9a7a/attachment.html>