On 3 June 2010 04:55, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 2 Jun 2010 12:14:48 +1000 Lex Trotman elextr@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.
- 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 :)
- 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:
- Any time a project is closed, save it's file list in the project
file.
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@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 exercise.
Cheers Lex
The implementation of #2 is described above.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel