[Geany-devel] Multiple instances of Geany issues
elextr at xxxxx
Thu Jun 3 06:38:57 UTC 2010
On 3 June 2010 04:55, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> On Wed, 2 Jun 2010 12:14:48 +1000
> Lex Trotman <elextr at gmail.com> wrote:
> (This is an answer to Eugene too)
>> 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 :)
> Yet the race is not that often - you'll need to change something for
> the same filetype in 2+ instances in the Set build commands
> (not the project) dialog. That should be movered, of course.
No matter how hard it is for it to occur, somewhere something bad will
happen to someone, so yes the race needs to be removed.
>> 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
> Do you mean a warning that the settings are saved, a question whether
> to save the settings, or a question whether to accept and save them?
Something like "This is a secondary instance of Geany, saving your
settings will overwrite the settings from your main instance,
Save/Cancel". They should still be applied locally of course,
otherwise why allow the prefs dialog at all.
> In any case, Edit -> Preferences -> Apply will be problematic. It saves
> the settings without closing the dialog, so there will be a question on
> each Apply.
True, annoying, but so is overwriting settings :)
>> 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
> My sm saves the entire configuration (including the file list) into a
> session file, so each Geany is restored with it's own settings and
> interface layout too.
> Thank you for writing the summary, it was about time. The behaviour
> looks quite reasonable behaviour IMHO. Let me add:
> 7. Any time a project is closed, save it's file list in the project
Yes, better to be explicit, I'd add "last close of a specific project wins"
> Most of the above are already available as patches. What remains:
> - Warnings (questions?) on Edit -> Preferences, Project -> Properties
> and Build -> Set build commands.
> - Limit Project -> Properties to saving the preferences only, and limit
> project_close() to saving the file list only.
> I can write the latter, if we agree on the above behaviour.
>> 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.
> Since I use Geany under X only, and my sm saves the recent files /
> projects for each Geany, merging the recent lists won't be very
> beneficial to me... So let the others decide.
In my experience the recent file list is only there to make it easier
to re-open files I incorrectly closed :-)
> On Wed, 2 Jun 2010 11:19:06 +0400
> Eugene Arshinov <earshinov at gmail.com> wrote:
>> 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.
> My sm requires the Build -> Set build commands changes to be saved
> immediately [save-filetypes-now.diff I sent on 24.05] to avoid the
> filetype files race described in the first paragraph.
> Aside from that, it neither requires nor implements #1 and #3..#7. The
> patches I wrote for some of them were to make Geany behaviour more
> useful and predictable.
What I'm trying to get at is what is the behaviour of Geany as a user
would see it after your patches are applied.
How would a Geany with your sm and whatever patches you choose to
apply behave against the (now) 7 points? The reason I'm asking is
that I've lost track of exactly what patches were proposed and their
effects and I think (but correct me if I'm wrong) that some of the
patches were superseded by others.
Talking on behalf of Enrico and Nick, my feeling is that we need to
make another branch in SVN and apply your recommended set of patches
and then people could try both implementations and compare them. I
think that in the end thats the only way to decide.
BTW both also need to update the documentation to describe the
resulting behaviour so other people don't need to go through this
> The implementation of #2 is described above.
> E-gards: Jimmy
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel