Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 16 Jun 2010 08:19:44 +1000 Lex Trotman ele...@gmail.com wrote: On 16 June 2010 04:12, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hmmm... Now that I think of it, how is a plugin supposed to save it's settings in a project file when closing a project connect to the project-save signal, the user_data is the g_key_file of the config file. [...] That's the point: project_close() calls write_config() with emit_signal = FALSE. So there is no project-save when closing a project, only on create project and Project - Properties - OK. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Mon, 14 Jun 2010 08:46:42 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Sat, 5 Jun 2010 12:10:01 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hi, - Limit Project - Properties to saving the preferences only, and limit project_close() to saving the file list only. Here are some changes I made to your original patch: [...] * AFAIK in Geany doc-comments (/**) are used only for symbols exported for plugins. I modified the comment before GeanySettingsTypes accordingly. Hmmm... Now that I think of it, how is a plugin supposed to save it's settings in a project file when closing a project, and why does it receive a signal when the dialog settings are confirmed? The former question applies to the original Geany (and the latter is my overlook, unless I'm missing something and a plugin can somehow add elements in the project settings dialog). -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
Hi,
- Limit Project - Properties to saving the preferences only, and
limit project_close() to saving the file list only.
Here it is, combined with the other save-* patches. BTW, when creating
a new project, it's immediately saved, both the settings and the file
list. So to avoid function cloning, and since it's unclear what save
behaviour will be approved, I decided to declare an enum save {dialog,
non-dialog, all} and use such argument for configuration_save() and
project's write_config().
What remains:
Decide on Save settings? prompts, or make it an option - see below.
Decide whether to merge the recent files in geany.conf in real time,
or have separate geany.conf and per-project recent file lists (since
we have per-project open file lists).
On Thu, 3 Jun 2010 16:38:57 +1000
Lex Trotman ele...@gmail.com wrote:
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.
The more I think about that, the less I like it. Not only will be such
a prompt irritating, especially for Apply, but how many times before the
user chooses the wrong button and overrides the settings, or loses them
after exiting geany?
Why not make it an option, default=on for compatibility, disabled for
the secondary instances (since they depend on it). Personally I'll just
leave it on and be done, while you will probably turn it off.
--
E-gards: Jimmy
--- ./src/build.c.orig 2010-06-05 08:43:55.0 +0300
+++ ./src/build.c 2010-06-05 08:51:33.0 +0300
@@ -2209,7 +2209,7 @@
}
prefdsts.nonfileregexstr = regex_pref;
if (build_read_commands(prefdsts, table_data, response) ft != NULL)
- ft-home_save_needed = TRUE;
+ filetypes_save_commands(ft);
build_free_fields(table_data);
build_menu_update(doc);
--- ./src/callbacks.c.orig 2010-05-14 14:24:09.0 +0300
+++ ./src/callbacks.c 2010-06-05 09:39:41.0 +0300
@@ -117,7 +117,8 @@
/* should only be called from on_exit_clicked */
static void quit_app(void)
{
- configuration_save();
+ if (!cl_options.new_instance)
+ configuration_save(GEANY_SAVE_SETTINGS_NON_DIALOG);
if (app-project != NULL)
project_close(FALSE); /* save project session files */
--- ./src/filetypes.c.orig 2010-05-14 14:24:09.0 +0300
+++ ./src/filetypes.c 2010-06-05 08:51:33.0 +0300
@@ -1343,16 +1343,15 @@
}
-gchar *filetypes_get_conf_extension(gint filetype_idx)
+static gchar *get_filetype_conf_extension(const GeanyFiletype *ft)
{
gchar *result;
- GeanyFiletype *ft = filetypes[filetype_idx];
if (ft-priv-custom)
return g_strconcat(ft-name, .conf, NULL);
/* Handle any special extensions different from lowercase filetype-name */
- switch (filetype_idx)
+ switch (ft-id)
{
case GEANY_FILETYPES_CPP: result = g_strdup(cpp); break;
case GEANY_FILETYPES_CS: result = g_strdup(cs); break;
@@ -1363,33 +1362,29 @@
}
-void filetypes_save_commands(void)
+gchar *filetypes_get_conf_extension(gint filetype_idx)
{
- gchar *conf_prefix = g_strconcat(app-configdir,
- G_DIR_SEPARATOR_S GEANY_FILEDEFS_SUBDIR G_DIR_SEPARATOR_S filetypes., NULL);
- guint i;
+ return get_filetype_conf_extension(filetypes[filetype_idx]);
+}
- for (i = 1; i filetypes_array-len; i++)
- {
- GKeyFile *config_home;
- gchar *fname, *ext, *data;
- if (filetypes[i]-home_save_needed)
- {
- ext = filetypes_get_conf_extension(i);
- fname = g_strconcat(conf_prefix, ext, NULL);
- g_free(ext);
- config_home = g_key_file_new();
- g_key_file_load_from_file(config_home, fname, G_KEY_FILE_KEEP_COMMENTS, NULL);
- build_save_menu(config_home, (gpointer)(filetypes[i]), GEANY_BCS_HOME_FT);
- data = g_key_file_to_data(config_home, NULL, NULL);
- utils_write_file(fname, data);
- g_free(data);
- g_key_file_free(config_home);
- g_free(fname);
- }
- }
- g_free(conf_prefix);
+void filetypes_save_commands(const GeanyFiletype *ft)
+{
+ gchar *ext = get_filetype_conf_extension(ft);
+ gchar *fname = g_strconcat(app-configdir,
+ G_DIR_SEPARATOR_S GEANY_FILEDEFS_SUBDIR G_DIR_SEPARATOR_S filetypes., ext, NULL);
+ GKeyFile *config_home;
+ gchar *data;
+
+ config_home = g_key_file_new();
+ g_key_file_load_from_file(config_home, fname, G_KEY_FILE_KEEP_COMMENTS, NULL);
+ build_save_menu(config_home, (gpointer)(ft), GEANY_BCS_HOME_FT);
+ data = g_key_file_to_data(config_home, NULL, NULL);
+ utils_write_file(fname, data);
+ g_free(data);
+ g_key_file_free(config_home);
+ g_free(fname);
+ g_free(ext);
}
@@ -1635,9 +1630,6 @@
guint i;
GeanyDocument *current_doc;
- /* save possibly changed commands before re-reading them */
- filetypes_save_commands();
-
/* reload filetype configs */
for (i = 0; i filetypes_array-len; i++)
{
--- ./src/filetypes.h.orig 2010-05-14 14:24:09.0 +0300
+++ ./src/filetypes.h 2010-06-05 08:51:33.0 +0300
@@ -139,7 +139,6 @@
gint
Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 2 Jun 2010 21:55:04 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: 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 appreciate. I was going to implement it myself, but, if you suggest first… :) Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
Sorry, forgot to answer this in the afternoon. On Thu, 3 Jun 2010 16:11:03 +1000% Lex Trotman ele...@gmail.com wrote: On 3 June 2010 01:08, Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman ele...@gmail.com wrote: On 2 June 2010 17:19, Eugene Arshinov earshi...@gmail.com wrote: 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 :( Thanks for explanation. 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. We may store files that were opened before the project internally and properly restore them after the project is closed. It's a simple idea, but it may be difficult to implement because practically we'll have to maintain internally two projects: default project and opened real project (if any). Also, this will introduce a new challenge for Geany's session management and SM: whether we need to save also default project if real project was opened when Geany exited? Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On 3 June 2010 01:08, Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman ele...@gmail.com wrote: On 2 June 2010 17:19, Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman ele...@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
Re: [Geany-devel] Multiple instances of Geany issues
On 3 June 2010 04:55, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Wed, 2 Jun 2010 12:14:48 +1000 Lex Trotman ele...@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 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 earshi...@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 ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Thu, 3 Jun 2010 16:38:57 +1000 Lex Trotman ele...@gmail.com wrote: 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. Here is what the patches do: Entire configuration ::= all geany.conf settings, the list of open files, the interface layout and the recent files / projects The project ::= project settings and project file list Edit - Preferences - OK or Apply: [save-settings-fix.diff] before: Save the entire configuration after: Save the Preferences dialog settings only Build - Set build commands: [save-filetypes-now.diff] before: Save nothing (the changed commands are saved on quit Geany or Project - Close or switch to another project) after: Save the changed commands Quit Geany: [save-settings-fix.diff, save-filetypes-now.diff] before: Save the entire configuration, the project and the changed build commands after: main instance: Save the configuration except for the settings from Edit - Preferences; save the project after: secondary instance: save the project As of the sm, it implements #2 in a more extended variant, requires save-filetypes-now.diff (for the filetypes files race), and neither requires nor implements #1 #3..#7. I'd prefer to discuss the multiple instances and session management separately. The user/interactive functionality of Geany is leading, while sm is just a technical problem of whoever implements it, and should not affect, much less define the user/interactive behaviour. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On 4 June 2010 02:56, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Thu, 3 Jun 2010 16:38:57 +1000 Lex Trotman ele...@gmail.com wrote: 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. Here is what the patches do: Entire configuration ::= all geany.conf settings, the list of open files, the interface layout and the recent files / projects The project ::= project settings and project file list Edit - Preferences - OK or Apply: [save-settings-fix.diff] before: Save the entire configuration after: Save the Preferences dialog settings only Build - Set build commands: [save-filetypes-now.diff] before: Save nothing (the changed commands are saved on quit Geany or Project - Close or switch to another project) after: Save the changed commands Quit Geany: [save-settings-fix.diff, save-filetypes-now.diff] before: Save the entire configuration, the project and the changed build commands after: main instance: Save the configuration except for the settings from Edit - Preferences; save the project after: secondary instance: save the project Ok, now its clear thanks, I'll try and put the table together on the weekend. As of the sm, it implements #2 in a more extended variant, requires save-filetypes-now.diff (for the filetypes files race), and neither requires nor implements #1 #3..#7 I'd prefer to discuss the multiple instances and session management separately. The user/interactive functionality of Geany is leading, while sm is just a technical problem of whoever implements it, and should not affect, much less define the user/interactive behaviour. The items affecting user visible behaviour were suggested as solutions to race conditions, if your sm doesn't expose that race and so is independent of the user visible changes thats great. In trying to understand the overall sm position those visible changes are relevant, and I'll note your sm can go either way. Cheers Lex -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman ele...@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. 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 :) 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?). 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. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On 2 June 2010 17:19, Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman ele...@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.
Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman ele...@gmail.com wrote: On 2 June 2010 17:19, Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman ele...@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. 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
Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 2 Jun 2010 12:14:48 +1000 Lex Trotman ele...@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. 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? 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. 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 file. 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. On Wed, 2 Jun 2010 11:19:06 +0400 Eugene Arshinov earshi...@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. 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
Re: [Geany-devel] Multiple instances of Geany issues
On Mon, 31 May 2010 13:35:26 +0400 Eugene Arshinov earshi...@gmail.com wrote: Just to mention, I ported to my SM branch the patches posted earlier in this thread. Also, I've changed the code to write changed recent files and projects lists to geany.conf as soon as possible instead of writing them on exit. [...] I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session, without as much as a xfce sm signal to the applications. The only error message I was able to record is ICE default IO error handler doing an exit(), pid = 8983, errno = 32. The pid is Geany's. After this one problem remains: handling of a project opened in several instances. It could be easy to apply immediate save technique for them too if we hadn't to maintain list of project's files. Currently, both the project settings and files are saved on any of Project - Preferences, Project - Close / New / Open and File - Quit. Following the logic of the other patches, IMHO Project - Preferences should save the settings only, and the other functions should save the file list only. As of a project open 2+ times, I expect the file list to be almost identical. It's not like running a -i instance, which starts with an empty file list. How should lists of files from several instances be combined? 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?.. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Tue, 1 Jun 2010 19:55:27 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Mon, 31 May 2010 13:35:26 +0400 Eugene Arshinov earshi...@gmail.com wrote: Just to mention, I ported to my SM branch the patches posted earlier in this thread. Also, I've changed the code to write changed recent files and projects lists to geany.conf as soon as possible instead of writing them on exit. [...] I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session, without as much as a xfce sm signal to the applications. The only error message I was able to record is ICE default IO error handler doing an exit(), pid = 8983, errno = 32. The pid is Geany's. It is terrible… I'm not experiencing this here in GNOME. Could you check previous revisions to determine when the bug appeared? After this one problem remains: handling of a project opened in several instances. It could be easy to apply immediate save technique for them too if we hadn't to maintain list of project's files. Currently, both the project settings and files are saved on any of Project - Preferences, Project - Close / New / Open and File - Quit. Following the logic of the other patches, IMHO Project - Preferences should save the settings only, and the other functions should save the file list only. Yes, precisely. As of a project open 2+ times, I expect the file list to be almost identical. It's not like running a -i instance, which starts with an empty file list. How should lists of files from several instances be combined? 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… Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Tue, 1 Jun 2010 21:15:09 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Tue, 1 Jun 2010 19:55:27 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session [...] It is terrible… I'm not experiencing this here in GNOME. Could you check previous revisions to determine when the bug appeared? 67 works, 68 fails. Stable. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
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. 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. Cheers Lex Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On 24 May 2010 18:18, Dimitar Zhekov hams...@mbox.contact.bg wrote: On Mon, 24 May 2010 14:38:53 +1000 Lex Trotman ele...@gmail.com wrote: And I just thought of another one, filetypes files, see filetypes_save_commands() called from main_quit() so there can be a race here too I think. Indeed. Now: - Why are the filetype saves postponded until quit? The way it was, didn't matter until multiple instances - Should the secondary instances do filetype saves? Well... oh why not? Make it work like projects. If we want the filetype save to be consistent with Edit - Preferences and Project - Properties, I think the commands should be saved on Build - Set build commands, for both main and secondary sessions. And since there is nothing else to be saved, main_quit() will not need to do filetypes_save_commands(), hence no race. Sounds like a plan. On 24 May 2010 01:04, Dimitar Zhekov hams...@mbox.contact.bg wrote: Can anyone please test if Windows waits for the WM_QUIT message to be processed before sending a WM_QUIT to another program on logout? Just open 2 Geany-s, modify a file in both of them and logout. If the Do you want to save? messages are displayed one by one, we'd better drop the locking/renaming at all, it has too many potential problems. Also answered in other thread. Yes, but I had half an hour today to test under Windows, and found yet another On dear!. On Win~1 logout, any modified files are silently discarded, and the .conf file is not saved (== the normal geany stop sequence is not executed). This is currently consistent with the X behaviour - both will lose your files/settings, that is - so I'm not sure it can be considered a bug... Either that or both are considered a bug, especially since you lose all your unsaved files, but thats separate from this discussion. But once we add sm support for X, the Win~1 logout should be dealt with too. (BTW, closing 2+ Wordpad-s works just fine for us - the save prompts appear one by one. Win~1 waits for a program to close before asking the next program to quit.) But what happens when there are no unsaved files to use the user as the serialising critical section :) Cheers Lex -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Mon, 24 May 2010 20:32:33 +1000
Lex Trotman ele...@gmail.com wrote:
On 24 May 2010 18:18, Dimitar Zhekov hams...@mbox.contact.bg wrote:
If we want the filetype save to be consistent with Edit - Preferences
and Project - Properties, I think the commands should be saved on
Build - Set build commands, for both main and secondary sessions.
And since there is nothing else to be saved, main_quit() will not need
to do filetypes_save_commands(), hence no race.
Sounds like a plan.
Here it is then.
(BTW, closing 2+ Wordpad-s works just fine for us - the save prompts
appear one by one. Win~1 waits for a program to close before asking
the next program to quit.)
But what happens when there are no unsaved files to use the user as
the serialising critical section :)
The save prompts one-by-one means that Win~1 sends WM_QUIT to foo.exe,
waits for the message to be processed (i.e. the foo.exe to be closed),
and only then sends WM_QUIT to bar.exe. That's fine even if there are no
unsaved files. I only needed the prompts as a visual indicator of the
message processing, not as serializer.
--
E-gards: Jimmy
--- ./src/build.c.orig 2010-05-14 14:24:08.0 +0300
+++ ./src/build.c 2010-05-24 15:35:45.0 +0300
@@ -2206,7 +2206,7 @@
}
prefdsts.nonfileregexstr = regex_pref;
if (build_read_commands(prefdsts, table_data, response) ft != NULL)
- ft-home_save_needed = TRUE;
+ filetypes_save_commands(ft);
build_free_fields(table_data);
build_menu_update(doc);
--- ./src/filetypes.c.orig 2010-05-14 14:24:09.0 +0300
+++ ./src/filetypes.c 2010-05-24 14:49:31.0 +0300
@@ -1343,16 +1343,15 @@
}
-gchar *filetypes_get_conf_extension(gint filetype_idx)
+static gchar *get_filetype_conf_extension(const GeanyFiletype *ft)
{
gchar *result;
- GeanyFiletype *ft = filetypes[filetype_idx];
if (ft-priv-custom)
return g_strconcat(ft-name, .conf, NULL);
/* Handle any special extensions different from lowercase filetype-name */
- switch (filetype_idx)
+ switch (ft-id)
{
case GEANY_FILETYPES_CPP: result = g_strdup(cpp); break;
case GEANY_FILETYPES_CS: result = g_strdup(cs); break;
@@ -1363,33 +1362,29 @@
}
-void filetypes_save_commands(void)
+gchar *filetypes_get_conf_extension(gint filetype_idx)
{
- gchar *conf_prefix = g_strconcat(app-configdir,
- G_DIR_SEPARATOR_S GEANY_FILEDEFS_SUBDIR G_DIR_SEPARATOR_S filetypes., NULL);
- guint i;
+ return get_filetype_conf_extension(filetypes[filetype_idx]);
+}
- for (i = 1; i filetypes_array-len; i++)
- {
- GKeyFile *config_home;
- gchar *fname, *ext, *data;
- if (filetypes[i]-home_save_needed)
- {
- ext = filetypes_get_conf_extension(i);
- fname = g_strconcat(conf_prefix, ext, NULL);
- g_free(ext);
- config_home = g_key_file_new();
- g_key_file_load_from_file(config_home, fname, G_KEY_FILE_KEEP_COMMENTS, NULL);
- build_save_menu(config_home, (gpointer)(filetypes[i]), GEANY_BCS_HOME_FT);
- data = g_key_file_to_data(config_home, NULL, NULL);
- utils_write_file(fname, data);
- g_free(data);
- g_key_file_free(config_home);
- g_free(fname);
- }
- }
- g_free(conf_prefix);
+void filetypes_save_commands(const GeanyFiletype *ft)
+{
+ gchar *ext = get_filetype_conf_extension(ft);
+ gchar *fname = g_strconcat(app-configdir,
+ G_DIR_SEPARATOR_S GEANY_FILEDEFS_SUBDIR G_DIR_SEPARATOR_S filetypes., ext, NULL);
+ GKeyFile *config_home;
+ gchar *data;
+
+ config_home = g_key_file_new();
+ g_key_file_load_from_file(config_home, fname, G_KEY_FILE_KEEP_COMMENTS, NULL);
+ build_save_menu(config_home, (gpointer)(ft), GEANY_BCS_HOME_FT);
+ data = g_key_file_to_data(config_home, NULL, NULL);
+ utils_write_file(fname, data);
+ g_free(data);
+ g_key_file_free(config_home);
+ g_free(fname);
+ g_free(ext);
}
@@ -1635,9 +1630,6 @@
guint i;
GeanyDocument *current_doc;
- /* save possibly changed commands before re-reading them */
- filetypes_save_commands();
-
/* reload filetype configs */
for (i = 0; i filetypes_array-len; i++)
{
--- ./src/filetypes.h.orig 2010-05-14 14:24:09.0 +0300
+++ ./src/filetypes.h 2010-05-24 14:10:12.0 +0300
@@ -139,7 +139,6 @@
gint project_list_entry;
gchar *projerror_regex_string;
gchar *homeerror_regex_string;
- gboolean home_save_needed;
#endif
};
@@ -179,7 +178,7 @@
void filetypes_load_config(gint ft_id, gboolean reload);
-void filetypes_save_commands(void);
+void filetypes_save_commands(const GeanyFiletype *ft);
void filetypes_select_radio_item(const GeanyFiletype *ft);
--- ./src/main.c.orig 2010-05-19 11:52:31.0 +0300
+++ ./src/main.c 2010-05-24 14:19:40.0 +0300
@@ -1132,7 +1132,6 @@
navqueue_free();
keybindings_free();
- filetypes_save_commands();
highlighting_free_styles();
templates_free_templates();
msgwin_finalize();
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Sun, 23 May 2010 08:04:33 +1000 Lex Trotman ele...@gmail.com wrote: You can get this behaviour by setting the hidden preference use_safe_file_saving, in that case utils_write_file uses g_file_set_contents which does _exactly_ what you describe, problem is it changes owners and permissions and doesn't work on some file systems, see thread [Geany-devel] Safe file saving - permissions issue and older ones on the same topic. Not exactly. geany.conf is a special case: it's more important to make sure that it is consistent than that it is saved. As of the permissions, do we support such thing as shared configuration directory? If not, they won't be an issue either. Enrico still gets headaches when he thinks about that thread :-) because the fix seems to require GIO which isn't available with the oldest glib supported by Geany so it would require two file handling codes to maintain. Both the g_open() used by you, and g_rename(), exist since 2.6; the documentation says they are wrappers for the respective POSIX functions. Personally I'd expect that the support for open(O_EXCL) is worse that rename(), the latter being also an ANSI function. [...] But OTOH I now think it unlikely that 0.19 will get problems (unless you do extreme things like my script :-), so we are only talking about sm versions needing the lock I think so too, and my X sm is raceless, so... Can anyone please test if Windows waits for the WM_QUIT message to be processed before sending a WM_QUIT to another program on logout? Just open 2 Geany-s, modify a file in both of them and logout. If the Do you want to save? messages are displayed one by one, we'd better drop the locking/renaming at all, it has too many potential problems. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On 24 May 2010 01:04, Dimitar Zhekov hams...@mbox.contact.bg wrote: On Sun, 23 May 2010 08:04:33 +1000 Lex Trotman ele...@gmail.com wrote: You can get this behaviour by setting the hidden preference use_safe_file_saving, in that case utils_write_file uses g_file_set_contents which does _exactly_ what you describe, problem is it changes owners and permissions and doesn't work on some file systems, see thread [Geany-devel] Safe file saving - permissions issue and older ones on the same topic. Not exactly. geany.conf is a special case: it's more important to make sure that it is consistent than that it is saved. Don't quite understand what you mean by this, I was just noting that your implementation is available already via an option and noting some reported issues with it. If there were no reported issues then it would be fine to use, but since there are issues I wouldn't want to enforce use of this method. As of the permissions, do we support such thing as shared configuration directory? If not, they won't be an issue either. I'm not sure if its explicitly supported or prohibited, I think its not thought about before, but it is possible, so someone will do it :) plus project files are not in the config directory so they are more likely to be relevant. Enrico still gets headaches when he thinks about that thread :-) because the fix seems to require GIO which isn't available with the oldest glib supported by Geany so it would require two file handling codes to maintain. Both the g_open() used by you, and g_rename(), exist since 2.6; the documentation says they are wrappers for the respective POSIX functions. Personally I'd expect that the support for open(O_EXCL) is worse that rename(), the latter being also an ANSI function. Both are documented as working and I can't find any recent reports of problems, note that exclusive access is the default in the windows CreateFile() call used by windows open() [...] But OTOH I now think it unlikely that 0.19 will get problems (unless you do extreme things like my script :-), so we are only talking about sm versions needing the lock I think so too, and my X sm is raceless, so.. Answered in the other thread, this one is intended to be for sm-less version to see what might be needed for 0.19 release. I'm presuming that one or other sm version will make it into 0.20 so we don't need to finalise that quickly. Can anyone please test if Windows waits for the WM_QUIT message to be processed before sending a WM_QUIT to another program on logout? Just open 2 Geany-s, modify a file in both of them and logout. If the Do you want to save? messages are displayed one by one, we'd better drop the locking/renaming at all, it has too many potential problems. Also answered in other thread. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel To summarise I propose that the only changes that need to be suggested for 0.19 are: * preference dialog preferences but not session preferences are saved when the dialog is closed and not when Geany is closed. * --new-instance instances should not save the geany.conf on close but the main instance should save the session part without modifying the dialog prefs part. These are usage issues not race issues, with this change --new-instances won't upset the main session but any instance can set the preferences and whichever set them last will be the ones used when starting any new Geanys. Post 0.19 perhaps the preferences dialog could have a reload button to allow multiple instances to re-sync with the saved prefs or it could even be auto if geany.conf was monitored. Saving of projects in --new-instances has benefits both ways, so I suggest leaving it as is for now (ie does save). Your patches save-settings-fix and save-filelist-fix do this fine so I suggest to Enrico/Nick that they should be part of 0.19. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Sat, 22 May 2010 12:55:40 +1000 Lex Trotman ele...@gmail.com wrote: [...] Isn't the race (as in broken file because 2+ instances write it at once) only a problem of the original SM implementation? I mean, a user can't close two projects or two Geany-s _that_ fast?.. No, but logout or shutdown can :-( Perhaps under Windows only? When I logout, Geany is simply killed, and the configuration file remains unchanged. If fact, if the normal application quit sequences were executed on logout (as under Windows), X11 woudn't need much of a session manager. That was on a local filesystem, if your home dir is NFSed from a server it would be slower and the time window for problems would be even greater. Indeed... Speaking of NFS (I read the patch) O_EXCL is problematic. On Linux, NFSv3+ and kernel 2.6+ are enough, so it should work, but I don't know about the other OS-es. http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html specifies how to do atomic O_EXCL on NFS, but uses link(), which is not available under Windows... [...] Oh dear!! One more Oh, dear situation: when Geany is _started_ with a project file, it writes the project-less file list into geany.conf. With the patch applied, at least the secondary instances don't do this... Given the number of Oh dears aboveI guess we have to do it properly, see response to your patch If the lock file is not successfully unlinked by Geany for some reason, for example a broken NFS connection, it'll have to be deleted manually. Well, that shoudn't be a big problem, but if there's some way to avoid it... -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On 22 May 2010 19:05, Dimitar Zhekov hams...@mbox.contact.bg wrote: On Sat, 22 May 2010 12:55:40 +1000 Lex Trotman ele...@gmail.com wrote: [...] Isn't the race (as in broken file because 2+ instances write it at once) only a problem of the original SM implementation? I mean, a user can't close two projects or two Geany-s _that_ fast?.. No, but logout or shutdown can :-( Perhaps under Windows only? When I logout, Geany is simply killed, and the configuration file remains unchanged. If fact, if the normal application quit sequences were executed on logout (as under Windows), X11 woudn't need much of a session manager. Thats kind of nasty, glad I always save my files. That was on a local filesystem, if your home dir is NFSed from a server it would be slower and the time window for problems would be even greater. Indeed... Speaking of NFS (I read the patch) O_EXCL is problematic. On Linux, NFSv3+ and kernel 2.6+ are enough, so it should work, but I don't know about the other OS-es. Thats correct, note I used g_open which seems to say that it works under windows as well. Windows actually has better locking than Unix in some ways, so if g_open uses it right it should be ok, the only potential problem is that it can be disabled by registery settings, according to Samba documentation anyway. http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html specifies how to do atomic O_EXCL on NFS, but uses link(), which is not available under Windows... Yeah, so I just used the plain file create lock. [...] Oh dear!! One more Oh, dear situation: when Geany is _started_ with a project file, it writes the project-less file list into geany.conf. With the patch applied, at least the secondary instances don't do this... Yes, saw your patch for that. Given the number of Oh dears aboveI guess we have to do it properly, see response to your patch If the lock file is not successfully unlinked by Geany for some reason, for example a broken NFS connection, it'll have to be deleted manually. Well, that shoudn't be a big problem, but if there's some way to avoid it... Not that I'm aware of, anybody who knows any other way that works on *ix and Windows is welcome to suggest it. Cheers Lex -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Sat, 22 May 2010 21:15:59 +1000 Lex Trotman ele...@gmail.com wrote: Speaking of NFS (I read the patch) O_EXCL is problematic [...] Thats correct, note I used g_open which seems to say that it works under windows as well. [...] the only potential problem is that it can be disabled by registery settings, according to Samba documentation anyway. If the lock file is not successfully unlinked by Geany for some reason, for example a broken NFS connection, it'll have to be deleted manually. Well, that shoudn't be a big problem, but if there's some way to avoid it... Not that I'm aware of, anybody who knows any other way that works on *ix and Windows is welcome to suggest it. Both on *ix and Win~1, hmmm... It just occured to me, what if we write the configuration into geany-some-unique-id.conf and then g_rename() it? Rename is an atomic operation; on NFS, you can not assume that if the operation failed the file was not renamed - well, we can emit a geany_debug() message for this. Even if Win~1 g_rename() is somehow broken, a MoveFileEx (..., MOVEFILE_REPLACE_EXISTING) will do. We know that both entries are files, they are on the same filesystem, and the destination file is writable - that eliminates almost any possible rename error. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Fri, 21 May 2010 16:53:56 +1000 Lex Trotman ele...@gmail.com wrote: On 21 May 2010 15:13, Eugene Arshinov earshi...@gmail.com wrote: 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. The way it can be implemented in detail (since I fubmled with the respective files in the last few days): save_dialog_prefs(GKeyFile *config) becomes global configuration_save_dialog_prefs(void). on_prefs_button_clicked() invokes configuration_save_dialog_prefs() instead of configuration_save(). configuration_save() does not invoke save_dialog_prefs(). quit_app() checks cl_options.new_instance to see if configuration_save() should be called. There are no other calls of configuration_save(), so that should suffice. 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. If this is applied to the projects, it would be something like: 1. Project - Properties always saves the project dialog properties, but not the file list. Of course, as Lex wrote out, it'll have to check if the project file was modified, and ask to save / save as / throw away (apply without saving?) the changes. 2. Closing a project or quitting Geany saves only the file list, and only if that's a main instance. I rarely open a project 2+ times, so RFC how useful would that be? -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Fri, 21 May 2010 14:34:36 +1000% Lex Trotman ele...@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? 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. * 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. 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. 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… 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. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
