Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Best regards, Eugene.
On 24 February 2010 20:04, Eugene Arshinov earshinov@gmail.com wrote:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
The overall issue of preferences, configuration and sessions for multiple instances is an interesting one (Sorry Eugene, I've got no answers but lots of questions)
Why is the first necessarily the "master"? Is this by definition or is there a reason? What if the first is started with -i? And what happens to configuration changes I make in other instances?
You see, I'm forgetful, if I had more than one Geany running (and I can see good reasons to do that) then I may forget which one is the "master" and change a preference in a different instance, so what happens to the conf file?
These are questions beyond just the session manager I know, but maybe the answer is/should be the same.
Cheers Lex
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Best regards, Eugene. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 24 Feb 2010 22:02:55 +1100 Lex Trotman elextr@gmail.com wrote:
The overall issue of preferences, configuration and sessions for multiple instances is an interesting one (Sorry Eugene, I've got no answers but lots of questions)
Why is the first necessarily the "master"? Is this by definition or is there a reason? What if the first is started with -i? And what happens to configuration changes I make in other instances?
You see, I'm forgetful, if I had more than one Geany running (and I can see good reasons to do that) then I may forget which one is the "master" and change a preference in a different instance, so what happens to the conf file?
At first Geany couldn't be run with multiple instances due to the socket code. I changed this but did nothing to avoid overwrite problems.
As Geany is written without the ability to share settings, and in some cases not able to update a setting at runtime, I think it would be too much work making Geany truly multi-instance like Firefox.
Regards, Nick
--- On Fri, 2/26/10, Nick Treleaven nick.treleaven@btinternet.com wrote:
From: Nick Treleaven nick.treleaven@btinternet.com Subject: Re: [Geany-devel] Race condition when saving geany.conf To: geany-devel@uvena.de Date: Friday, February 26, 2010, 3:39 PM On Wed, 24 Feb 2010 22:02:55 +1100 Lex Trotman elextr@gmail.com wrote:
The overall issue of preferences, configuration and
sessions for multiple
instances is an interesting one (Sorry Eugene, I've
got no answers but lots
of questions)
Why is the first necessarily the "master"? Is this by definition or is there a reason? What if the first is started with -i? And what happens to configuration changes I make
in other instances?
You see, I'm forgetful, if I had more than one Geany
running (and I can see
good reasons to do that) then I may forget which one
is the "master" and
change a preference in a different instance, so what
happens to the conf
file?
At first Geany couldn't be run with multiple instances due to the socket code. I changed this but did nothing to avoid overwrite problems.
As Geany is written without the ability to share settings, and in some cases not able to update a setting at runtime, I think it would be too much work making Geany truly multi-instance like Firefox.
I agree, it's a lot of work. Those who need to run multiple instances should consider using -c/--config option.
On 27 February 2010 02:39, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Wed, 24 Feb 2010 22:02:55 +1100 Lex Trotman elextr@gmail.com wrote:
The overall issue of preferences, configuration and sessions for multiple instances is an interesting one (Sorry Eugene, I've got no answers but
lots
of questions)
Why is the first necessarily the "master"? Is this by definition or is there a reason? What if the first is started with -i? And what happens to configuration changes I make in other instances?
You see, I'm forgetful, if I had more than one Geany running (and I can
see
good reasons to do that) then I may forget which one is the "master" and change a preference in a different instance, so what happens to the conf file?
At first Geany couldn't be run with multiple instances due to the socket code. I changed this but did nothing to avoid overwrite problems.
As Geany is written without the ability to share settings, and in some cases not able to update a setting at runtime, I think it would be too much work making Geany truly multi-instance like Firefox.
No problem, then we need to put a big warning in the manual then so that people know not to configure their file manager to run separate instances or the forgetful behaviour kicks in again, "now which instance did I run by double click on a file again?" :-)
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
When several instances of Geany quit in the same time, there is a high possibility of a conflict. [...]
I can see two solutions for this problem. [...]
On Wed, 24 Feb 2010 22:02:55 +1100 Lex Trotman elextr@gmail.com wrote:
You see, I'm forgetful, if I had more than one Geany running (and I can see good reasons to do that) then I may forget which one is the "master" and change a preference in a different instance, so what happens to the conf file?
Perhaps a third solution is possible.
On Save Yourself:
1. Temporarily clear Project Based Session Files. 2. Save the configuration as smclientid.conf instead of geany.conf. 3. Don't save the project - all it's settings are saved when the project is configmed, and the .conf file will take care of the filelist.
On startup, with an smclientid argument present:
1. Temporarily clear Project Based Session Files. 2. Load the configuration from smclientid.conf instead of geany.conf. 3. Don't load anything else. That should happen more or less automatically, once you don't load geany.conf.
The smclientid.conf file may be removed after loading, or with the XSM DiscardCommand.
As far as I can tell, that will avoid any conf/project races, save the file list and all per-file Geany options (Read Only, Wrap, ...) no matter if they are part of a project or not, and even save the main options per-instance. Plus, it doesn't seem very hard to write, at least to me.
-- E-gards: Jimmy
On Wed, 24 Feb 2010 20:11:43 +0300 Dimitar Zhekov hamster@mbox.contact.bg wrote:
- Temporarily clear Project Based Session Files.
To clarify this a bit, since "temporarily clear" obviously won't work just like that.
For saving, a save_configuration_file(name, gboolean project_session) should suffice. The project_session argument will determine the behaviour, while the project_prefs.project_session value will be saved in the .conf file. The standard save_configuration() will then invoke save_configuration_file(geany.conf, project_prefs.project_session).
For loading, clearing project_prefs.project_session in main.c:load_startup_files() before invoking load_session_project_file() and restoring it afterwards should do the trick. It'll be techically cleaner to pass an additional force_non_project_session argument to load_session_project_file() -> project_load_file() -> load_config(), but not worth the effort IMHO.
-- E-gards: Jimmy
On Wed, 24 Feb 2010 20:11:43 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
When several instances of Geany quit in the same time, there is a high possibility of a conflict. [...]
I can see two solutions for this problem. [...]
On Wed, 24 Feb 2010 22:02:55 +1100 Lex Trotman elextr@gmail.com wrote:
You see, I'm forgetful, if I had more than one Geany running (and I can see good reasons to do that) then I may forget which one is the "master" and change a preference in a different instance, so what happens to the conf file?
Perhaps a third solution is possible.
On Save Yourself:
- Temporarily clear Project Based Session Files.
- Save the configuration as smclientid.conf instead of geany.conf.
- Don't save the project - all it's settings are saved when the
project is configmed, and the .conf file will take care of the filelist.
On startup, with an smclientid argument present:
- Temporarily clear Project Based Session Files.
- Load the configuration from smclientid.conf instead of geany.conf.
- Don't load anything else. That should happen more or less
automatically, once you don't load geany.conf.
The smclientid.conf file may be removed after loading, or with the XSM DiscardCommand.
As far as I can tell, that will avoid any conf/project races, save the file list and all per-file Geany options (Read Only, Wrap, ...) no matter if they are part of a project or not, and even save the main options per-instance. Plus, it doesn't seem very hard to write, at least to me.
Hi.
I'm not sure I understand you message correctly, but the problem I described is about saving the global Geany settings, not about the way how to pass instances' settings "across restarts".
The latter is an important topic too, but I can see no significant problems with the behaviour accepted in the different branch of this thread. There are some problems, like an example below, but they aren't worth solving because users will be aware that settings are stored only by the "main instance" and won't edit settings in "new instances". And the global settings will be always correctly restored from geany.conf.
[An example insignificant problem] If you change something in an instance run with "-i" and restart, you'll loose your changes as they won't be saved anywhere.
Best regards, Eugene.
On Tue, 2 Mar 2010 16:02:48 +0300 Eugene Arshinov earshinov@gmail.com wrote:
I'm not sure I understand you message correctly, but the problem I described is about saving the global Geany settings, not about the way how to pass instances' settings "across restarts".
In short, save <smclientid>.conf files instead of "geany.conf". That will not save any global options, so if you restart the session and then launch a new geany, it will not use such saved options. However, if you launch a geany instance _without_ restarting the session, exactly the same thing will happen. The question seems, then, is save session considered to be "quit and save my settings for future use", or "next time, restore the things exactly as they were".
[...]
[An example insignificant problem] If you change something in an instance run with "-i" and restart, you'll loose your changes as they won't be saved anywhere.
Another insignificant problem is that if the same project is open in two or more instances, that may cause a project file race.
More important than that, however, the --config option (if any) passed to geany should be replicated in the session arguments. First, the geany socket is in the configuration directory, which means one primary instance per directory. Second, if you restart the instances without --config, they will all grab the default geany.conf, forgetting their's saved <directory>/geany.conf files.
-- E-gards: Jimmy
On Tue, 2 Mar 2010 20:25:50 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Tue, 2 Mar 2010 16:02:48 +0300 Eugene Arshinov earshinov@gmail.com wrote:
I'm not sure I understand you message correctly, but the problem I described is about saving the global Geany settings, not about the way how to pass instances' settings "across restarts".
In short, save <smclientid>.conf files instead of "geany.conf". That will not save any global options, so if you restart the session and then launch a new geany, it will not use such saved options. However, if you launch a geany instance _without_ restarting the session, exactly the same thing will happen.
And who saves the global options then? We need them written, for being read by new instances of geany.
The question seems, then, is save session considered to be "quit and save my settings for future use", or "next time, restore the things exactly as they were".
Of course, the second option is the right answer, but settings are a special case. To make things simple (both for developers and users), the settings will be saved by the main instance only, and users won't be supposed to change preferences in "new instances". It will make it legitimate to store the only version of settings (i.e., the version controlled by the main instance) in the only place for all instances, and this place is geany.conf. Reloading the global settings in "new instances" after restart, as it will happen, is not surprising and, I think, even desirable by users. So, I like the solution accepted elsewhere (in another thread) as it almost satisfies the criteria "next time, restore the things exactly as they were", being easy and simple and not requiring temporary files to be created and handled.
[...]
[An example insignificant problem] If you change something in an instance run with "-i" and restart, you'll loose your changes as they won't be saved anywhere.
Another insignificant problem is that if the same project is open in two or more instances, that may cause a project file race.
More important than that, however, the --config option (if any) passed to geany should be replicated in the session arguments. First, the geany socket is in the configuration directory, which means one primary instance per directory. Second, if you restart the instances without --config, they will all grab the default geany.conf, forgetting their's saved <directory>/geany.conf files.
The --config option is added to the restart command, if it was specified when the instance was run. This is already implemented.
Best regards, Eugene.
On Tue, 2 Mar 2010 22:40:48 +0300 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 2 Mar 2010 20:25:50 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Tue, 2 Mar 2010 16:02:48 +0300 Eugene Arshinov earshinov@gmail.com wrote:
In short, save <smclientid>.conf files instead of "geany.conf". That will not save any global options, so if you restart the session and then launch a new geany, it will not use such saved options. However, if you launch a geany instance _without_ restarting the session, exactly the same thing will happen.
And who saves the global options then? We need them written, for being read by new instances of geany.
Nobody. Please forget the sessions for a moment - if you launch a new geany, right now, will any currently unsaved options from your running geany(s) be magically saved by some primary instance? No, you'll get what's in geany.conf right now. And you'll get absolutely the same after you restart.
Want to save some unsaved options, so a newly launched geany will use them? Just go to the instance you want the options from and do it. Before or after restart, that doesn't matter.
Saving some "global options" contradicts "restore everything exactly". While you work, the unsaved options (if any) are not autosaved on each X minutes or something - so why they should be autosaved only because there will be some "downtime" before you continue to work?
-- E-gards: Jimmy
On Tue, 2 Mar 2010 22:49:17 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Tue, 2 Mar 2010 22:40:48 +0300 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 2 Mar 2010 20:25:50 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Tue, 2 Mar 2010 16:02:48 +0300 Eugene Arshinov earshinov@gmail.com wrote:
In short, save <smclientid>.conf files instead of "geany.conf". That will not save any global options, so if you restart the session and then launch a new geany, it will not use such saved options. However, if you launch a geany instance _without_ restarting the session, exactly the same thing will happen.
And who saves the global options then? We need them written, for being read by new instances of geany.
Nobody. Please forget the sessions for a moment - if you launch a new geany, right now, will any currently unsaved options from your running geany(s) be magically saved by some primary instance? No, you'll get what's in geany.conf right now. And you'll get absolutely the same after you restart.
Want to save some unsaved options, so a newly launched geany will use them? Just go to the instance you want the options from and do it. Before or after restart, that doesn't matter.
Saving some "global options" contradicts "restore everything exactly". While you work, the unsaved options (if any) are not autosaved on each X minutes or something - so why they should be autosaved only because there will be some "downtime" before you continue to work?
Okay, now I understand your suggestion. In my opinion, your version is more flexible (a user controls when and which settings are saved, not Geany), but most users will never need that flexibility. Again, your version may be more clear for users (instances have same settings after restart), but I still like the accepted behaviour more, for the reasons I described in the prev. message.
A side note. I think the two suggestions are rather orthogonal. For example, it is possible to use temporary files for storing settings across restarts and use the main-instance-auto-saves behaviour at the same time. Another example (drop main-instance-auto-save, but still use global geany.conf after restart) isn't so good as it may cause a loss of settings changes.
Other opinions?
Best regards, Eugene.
Hi.
First, let me apologize for not noticing the sm option replication. Mea culpa.
Now to the point. I went ahead and tested the sm, and ran into a problem: in the X11 session, the geany instances are stored both as Client_ (by sm.c) and Legacy_ (by gtk/gdk, as in 0.18).
Normally a gdk_set_sm_client_id(new_client_id) would fix this, but there is a side effect. The XSM window settings (maximized state, desktop# etc.) are applied to the first window open by the session client, and since sm_init() is run after the main geany window is created:
1. Geany always appears on the first desktop. 2. If you choose File -> Open or Edit -> Preferences, and geany was maximized, the Open or Preferences dialog appears maximized instead. That depends on the dialog, for example, Open may also "appear" minimized, while Find seems unaffected.
Using gdk_set_sm_client_id() and moving sm_init() before main_init() will fix this, and since sm_init() is very limited, that shouldn't break anything... but I'm not sure.
-- E-gards: Jimmy
On Wed, 3 Mar 2010 11:32:57 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
Hi.
Now to the point. I went ahead and tested the sm, and ran into a problem: in the X11 session, the geany instances are stored both as Client_ (by sm.c) and Legacy_ (by gtk/gdk, as in 0.18).
Normally a gdk_set_sm_client_id(new_client_id) would fix this, but there is a side effect. The XSM window settings (maximized state, desktop# etc.) are applied to the first window open by the session client, and since sm_init() is run after the main geany window is created:
- Geany always appears on the first desktop.
- If you choose File -> Open or Edit -> Preferences, and geany was
maximized, the Open or Preferences dialog appears maximized instead. That depends on the dialog, for example, Open may also "appear" minimized, while Find seems unaffected.
Using gdk_set_sm_client_id() and moving sm_init() before main_init() will fix this, and since sm_init() is very limited, that shouldn't break anything... but I'm not sure.
Hi.
Thanks for suggestion, now committed. It's the first time I'm using SM so I didn't even know about gdk_set_sm_client_id(). Also, could you please tell me how to view the X11 session (you are writing about "Client_" and "Legacy_")?
Best regards, Eugene.
On Wed, 19 May 2010 11:01:35 +0400 Eugene Arshinov earshinov@gmail.com wrote:
[...] Also, could you please tell me how to view the X11 session (you are writing about "Client_" and "Legacy_")?
It's stored somewhere in your home directory. Normally there would be one or more text files listing all session applications, with their XSM and window properties, under ".cache" or ".config"; and other files created by the individual applications.
The Xfce SM uses text lines starting with "Client_" for XSMP and "Legacy_" for the previous (XAtom based IIRC) session protocol. Don't know about the others.
-- E-gards: Jimmy
On Wed, 19 May 2010 10:33:32 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Wed, 19 May 2010 11:01:35 +0400 Eugene Arshinov earshinov@gmail.com wrote:
[...] Also, could you please tell me how to view the X11 session (you are writing about "Client_" and "Legacy_")?
It's stored somewhere in your home directory. Normally there would be one or more text files listing all session applications, with their XSM and window properties, under ".cache" or ".config"; and other files created by the individual applications.
The Xfce SM uses text lines starting with "Client_" for XSMP and "Legacy_" for the previous (XAtom based IIRC) session protocol. Don't know about the others.
Okay, found them here as *.desktop files in ~/.config/gnome-session/.
Best regards, Eugene.
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Perhaps without clearly answering you, here's my non-technical thoughts:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
Project settings should still be saved in all instances. Plugin settings should not be saved in new instances, so we would need to introduce an API callback signal for save-settings and all plugins would need updating.
Regards, Nick
I haven't paid careful attention to this thread, but on several projects I've worked on, we've adopted a "last to save, wins" philosophy for situations (somewhat) similar to this.
I've learned to deal with that in several applications including nedit, and it seems to be a reasonable approach, requiring, iiuc, no work.
Randy Kramer
On Friday 26 February 2010 10:15:02 am Nick Treleaven wrote:
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
On 27 February 2010 03:36, Randy Kramer rhkramer@gmail.com wrote:
I haven't paid careful attention to this thread, but on several projects I've worked on, we've adopted a "last to save, wins" philosophy for situations (somewhat) similar to this.
I've learned to deal with that in several applications including nedit, and it seems to be a reasonable approach, requiring, iiuc, no work.
Hi Randy,
As I understand it, what Eugene is worried about is that when several instances finish at the same time without synchronisation it might not be last wins so much as random config file wins. Several instances will all try to finish at once if you shut down/logout with several Geanys out of their bottle :-)
Cheers Lex
Randy Kramer
On Friday 26 February 2010 10:15:02 am Nick Treleaven wrote:
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex,
Now I understand--thanks very much for the clarification!
Randy Kramer
On Friday 26 February 2010 05:31:09 pm Lex Trotman wrote:
On 27 February 2010 03:36, Randy Kramer rhkramer@gmail.com wrote:
I haven't paid careful attention to this thread, but on several projects I've worked on, we've adopted a "last to save, wins" philosophy for situations (somewhat) similar to this.
As I understand it, what Eugene is worried about is that when several instances finish at the same time without synchronisation it might not be last wins so much as random config file wins. Several instances will all try to finish at once if you shut down/logout with several Geanys out of their bottle :-)
On 27 February 2010 02:15, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Perhaps without clearly answering you, here's my non-technical thoughts:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
I havn't looked in detail at what the -i option does but I assume it doesn't use or accept socket connections. If so then I assume all Geany commands without the -i will be the same instance, and this is the one that should be able to save. There needs to be a visual distinction of instances that can & can't save. I wouldn't worry about the other -i instances being able to get settings until the main closes.
As I implied in my comment on another message, my use case was to have the filemanager programmed to start a new instance if I double click to look at a file so it doesn't interfere with my "main" instance. I know the socket system was intended to cause exactly the opposite but I've always been a contrary sorta person ;-)
Cheers Lex
Project settings should still be saved in all instances. Plugin settings should not be saved in new instances, so we would need to introduce an API callback signal for save-settings and all plugins would need updating.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 27 Feb 2010 09:05:12 +1100 Lex Trotman elextr@gmail.com wrote:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
I havn't looked in detail at what the -i option does but I assume it doesn't use or accept socket connections.
Yes. The socket code only works for the 'main' instance.
If so then I assume all Geany commands without the -i will be the same instance, and this is the one that should be able to save.
(If a second instance of geany is run without passing filenames to the first, -i is implied).
There needs to be a visual distinction of instances that can & can't save.
I agree, otherwise the user might think there was a bug saving settings.
I wouldn't worry about the other -i instances being able to get settings until the main closes.
This was just an extra feature I personally would find useful (force saving settings without quitting). Otherwise you would have to quit just to 'update' settings for new instances to read.
Also, force saving settings can be useful when developing (e.g. running recent trunk code for real work, as I do to help test it). So I don't lose e.g. paragraphs in Scribble due to a segfault.
Regards, Nick
On Mon, 1 Mar 2010 16:08:18 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 27 Feb 2010 09:05:12 +1100 Lex Trotman elextr@gmail.com wrote:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
I havn't looked in detail at what the -i option does but I assume it doesn't use or accept socket connections.
Yes. The socket code only works for the 'main' instance.
If so then I assume all Geany commands without the -i will be the same instance, and this is the one that should be able to save.
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
There needs to be a visual distinction of instances that can & can't save.
I agree, otherwise the user might think there was a bug saving settings.
Any proposal for this visual distinction?
I wouldn't worry about the other -i instances being able to get settings until the main closes.
This was just an extra feature I personally would find useful (force saving settings without quitting). Otherwise you would have to quit just to 'update' settings for new instances to read.
Also, force saving settings can be useful when developing (e.g. running recent trunk code for real work, as I do to help test it). So I don't lose e.g. paragraphs in Scribble due to a segfault.
Agree, that would be useful. I can implement "Tools > Save Config" myself. At the same time, I won't complain if anyones take this job ;)
Best regards, Eugene.
On 02.03.2010 13:23, Eugene Arshinov wrote:
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
Shouldn't it just bring the existing instance on top without creating a new instance? That's what I would expect (i.e. you only get a new instance if you use -i).
Best regards.
On Tue, 02 Mar 2010 18:50:28 +0100% Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
On 02.03.2010 13:23, Eugene Arshinov wrote:
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
Shouldn't it just bring the existing instance on top without creating a new instance? That's what I would expect (i.e. you only get a new instance if you use -i).
Hi. Maybe my quotation is not in a quite right place, what I was talking about is that the main instance (and only it) should save the settings.
Speaking about the behaviour you mentioned, I'd like your version too. But, in my opinion, this feature is too minor to pay attention to. Anyway, I'll implement the new version if it gets more votes (especially from Nick and Enrico); this task must be really easy. So, let's wait for other opinions.
Best regards, Eugene.
On Tue, 02 Mar 2010 18:50:28 +0100 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
Shouldn't it just bring the existing instance on top without creating a new instance? That's what I would expect (i.e. you only get a new instance if you use -i).
The idea is that the user can just click the desktop icon to get a new window. Raising an existing window is a Window Manager function IMO.
Regards, Nick
Am Freitag, den 05.03.2010, 16:54 +0000 schrieb Nick Treleaven:
On Tue, 02 Mar 2010 18:50:28 +0100 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
Shouldn't it just bring the existing instance on top without creating a new instance? That's what I would expect (i.e. you only get a new instance if you use -i).
The idea is that the user can just click the desktop icon to get a new window. Raising an existing window is a Window Manager function IMO.
That's exactly the behaviour I'd expect too. :)
Regards, Dominic
On 05.03.2010 22:49, Dominic Hopf wrote:
Am Freitag, den 05.03.2010, 16:54 +0000 schrieb Nick Treleaven:
On Tue, 02 Mar 2010 18:50:28 +0100 Thomas Martitzthomas.martitz@student.HTW-Berlin.de wrote:
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
Shouldn't it just bring the existing instance on top without creating a new instance? That's what I would expect (i.e. you only get a new instance if you use -i).
The idea is that the user can just click the desktop icon to get a new window. Raising an existing window is a Window Manager function IMO.
That's exactly the behaviour I'd expect too. :)
Regards, Dominic
I only expect this for apps which are truly multi-instance aware. This doesn't apply for geany. And even then, the desktop icon could have the -i in the run command and you would achieve the same. I think the desktop icon is well in the hands of geany (IIRC make/.waf install creates some shortcuts which we could define to have -i).
For example, I expect this from apps like OpenOffice where a new instance is merely a new document. But I don't expect this from e.g. Pidgin where it's clear that 2 instances won't work well (and in fact, opening pidgin via some icon on the desktop/in the menus just raises the current instance).
I disagree with this being a window manager function. The system should just try to create a new instance. The app then decides whether to open a new instance or not (the current behavior).
Best regards.
On Sun, 07 Mar 2010 01:17:03 +0100, Thomas wrote:
On 05.03.2010 22:49, Dominic Hopf wrote:
Am Freitag, den 05.03.2010, 16:54 +0000 schrieb Nick Treleaven:
On Tue, 02 Mar 2010 18:50:28 +0100 Thomas Martitzthomas.martitz@student.HTW-Berlin.de wrote:
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
Shouldn't it just bring the existing instance on top without creating a new instance? That's what I would expect (i.e. you only get a new instance if you use -i).
The idea is that the user can just click the desktop icon to get a new window. Raising an existing window is a Window Manager function IMO.
That's exactly the behaviour I'd expect too. :)
Regards, Dominic
I only expect this for apps which are truly multi-instance aware. This doesn't apply for geany. And even then, the desktop icon could have the -i in the run command and you would achieve the same. I think the desktop icon is well in the hands of geany (IIRC make/.waf install creates some shortcuts which we could define to have -i).
For example, I expect this from apps like OpenOffice where a new instance is merely a new document. But I don't expect this from e.g. Pidgin where it's clear that 2 instances won't work well (and in fact, opening pidgin via some icon on the desktop/in the menus just raises the current instance).
I disagree with this being a window manager function. The system should just try to create a new instance. The app then decides whether to open a new instance or not (the current behavior).
I'd like to keep the current behaviour (i.e. create a new instance). Rather, we could add, if necessary, a command line option which simply raises the window of the existing instance.
Regards, Enrico
On Tue, 2 Mar 2010 15:23:31 +0300% Eugene Arshinov earshinov@gmail.com wrote:
On Mon, 1 Mar 2010 16:08:18 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 27 Feb 2010 09:05:12 +1100 Lex Trotman elextr@gmail.com wrote:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
I havn't looked in detail at what the -i option does but I assume it doesn't use or accept socket connections.
Yes. The socket code only works for the 'main' instance.
If so then I assume all Geany commands without the -i will be the same instance, and this is the one that should be able to save.
(If a second instance of geany is run without passing filenames to the first, -i is implied).
I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of "new-instances", i.e., those instances should not touch any global data, either the default session or the settings.
Now committed, together with "Tools > Save configuration" menu item. Though, I think we should think of a better name for it as currently "Save configuration" and "Reload configuration" mean different things by configuration, which will probably confuse users.
There needs to be a visual distinction of instances that can & can't save.
I agree, otherwise the user might think there was a bug saving settings.
Any proposal for this visual distinction?
Best regards, Eugene.
On Wed, 19 May 2010 11:07:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 2 Mar 2010 15:23:31 +0300% Eugene Arshinov earshinov@gmail.com wrote:
Lex Trotman elextr@gmail.com wrote:
If so then I assume all Geany commands without the -i will be the same instance, and this is the one that should be able to save.
(If a second instance of geany is run without passing filenames to the first, -i is implied).
Not quite, the post-0.18 versions of geany include a socket-file option. Personally I prefer one socket per desktop, with the same configuration directory.
Now committed, together with "Tools > Save configuration" menu item.
I hope "Save configuration" works for all instances, and not for the "main" instance only, as someone suggested. With "main", the options can be saved by "Edit -> Preferences -> OK" anyway, and I would like to be able to save them from a secondary instance, and run a new Geany with them.
-- E-gards: Jimmy
On Wed, 19 May 2010 14:09:57 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Wed, 19 May 2010 11:07:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Now committed, together with "Tools > Save configuration" menu item.
I hope "Save configuration" works for all instances, and not for the "main" instance only, as someone suggested. With "main", the options can be saved by "Edit -> Preferences -> OK" anyway, and I would like to be able to save them from a secondary instance, and run a new Geany with them.
Preference -> OK is a good point… I did not know it saves configuration file immediately (yeah, again). Seems that it makes "Save configuration" unnecessary (at least, for main instance).
I am against enabling "Save configuration" for secondary instances because (in case of current behaviour when the main instance saves configuration automatically on exit) it may confuse users. Suppose you have main instance and secondary instance running. You change preferences in the secondary instance and use "Save configuration", then restart the main instance in order to make it apply new settings… and when the main instance is closing it silently overwrites them. So I thinks it's reasonable to force users to change their preferences in main instance only.
Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
Best regards, Eugene.
On Wed, 19 May 2010 22:13:40 +0400, Eugene wrote:
On Wed, 19 May 2010 14:09:57 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Wed, 19 May 2010 11:07:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Now committed, together with "Tools > Save configuration" menu item.
I hope "Save configuration" works for all instances, and not for the "main" instance only, as someone suggested. With "main", the options can be saved by "Edit -> Preferences -> OK" anyway, and I would like to be able to save them from a secondary instance, and run a new Geany with them.
Preference -> OK is a good point… I did not know it saves configuration file immediately (yeah, again). Seems that it makes "Save configuration" unnecessary (at least, for main instance).
I am against enabling "Save configuration" for secondary instances because (in case of current behaviour when the main instance saves configuration automatically on exit) it may confuse users. Suppose you have main instance and secondary instance running. You change preferences in the secondary instance and use "Save configuration", then restart the main instance in order to make it apply new settings… and when the main instance is closing it silently overwrites them. So I thinks it's reasonable to force users to change their preferences in main instance only.
Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary.
Regards, Enrico
On Wed, 19 May 2010 23:05:26 +0200% Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 May 2010 22:13:40 +0400, Eugene wrote:
On Wed, 19 May 2010 14:09:57 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Wed, 19 May 2010 11:07:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Now committed, together with "Tools > Save configuration" menu item.
I hope "Save configuration" works for all instances, and not for the "main" instance only, as someone suggested. With "main", the options can be saved by "Edit -> Preferences -> OK" anyway, and I would like to be able to save them from a secondary instance, and run a new Geany with them.
Preference -> OK is a good point… I did not know it saves configuration file immediately (yeah, again). Seems that it makes "Save configuration" unnecessary (at least, for main instance).
I am against enabling "Save configuration" for secondary instances because (in case of current behaviour when the main instance saves configuration automatically on exit) it may confuse users. Suppose you have main instance and secondary instance running. You change preferences in the secondary instance and use "Save configuration", then restart the main instance in order to make it apply new settings… and when the main instance is closing it silently overwrites them. So I thinks it's reasonable to force users to change their preferences in main instance only.
Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary.
(this is also a reply to Dimitar)
Well, then it's not a big deal to only save_dialog_prefs() after the Preferences dialog is closed and save everything but dialog prefs (UI prefs, session etc.) on exit. That is logical and will solve the problem.
Also, it is safe and reasonable to save preferences (and only them) after the dialog is closed even in secondary instances. Then "Save Configuration" won't be needed, unless someone expects this menu item to also save UI prefs, opened files and other things (which is a bad idea).
Best regards, Eugene.
On Thu, 20 May 2010 22:52:49 +0400, Eugene wrote:
Hey,
sorry for the delay, I just don't manage to keep up with this stuff :(.
Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary.
(this is also a reply to Dimitar)
Well, then it's not a big deal to only save_dialog_prefs() after the Preferences dialog is closed and save everything but dialog prefs (UI prefs, session etc.) on exit. That is logical and will solve the problem.
Sounds ok to me. But I didn't have a look at the code to find maybe some potential problems with such a change.
Regards, Enrico
On Sun, 30 May 2010 19:36:14 +0200% Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 20 May 2010 22:52:49 +0400, Eugene wrote:
Hey,
sorry for the delay, I just don't manage to keep up with this stuff :(.
No problem.
Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary.
(this is also a reply to Dimitar)
Well, then it's not a big deal to only save_dialog_prefs() after the Preferences dialog is closed and save everything but dialog prefs (UI prefs, session etc.) on exit. That is logical and will solve the problem.
Sounds ok to me. But I didn't have a look at the code to find maybe some potential problems with such a change.
Okay. Just for clarity, the discussion about this topic has moved to a new thread http://lists.uvena.de/geany-devel/2010-May/002358.html. Dimitar and Lex have already posted there some patches.
I've included those patches into my local SM repository. After I finish implementing the same behaviour for recent files and projects I'll commit everything to my SVN branch.
Best regards, Eugene.
On Sun, 30 May 2010 22:43:54 +0400, Eugene wrote:
Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary.
(this is also a reply to Dimitar)
Well, then it's not a big deal to only save_dialog_prefs() after the Preferences dialog is closed and save everything but dialog prefs (UI prefs, session etc.) on exit. That is logical and will solve the problem.
Sounds ok to me. But I didn't have a look at the code to find maybe some potential problems with such a change.
Okay. Just for clarity, the discussion about this topic has moved to a new thread http://lists.uvena.de/geany-devel/2010-May/002358.html. Dimitar and Lex have already posted there some patches.
Oops, sorry. I still didn't manage to follow the thread. It's currently way too time-consuming and also, as you know, I'm not such a big fan of this multiple instance stuff anyway. Geany was never meant to work like this. Anyway, I'll concentrate on the upcoming release for now and read and reply in the mentioned thread later (hopefully still this weekend).
Regards, Enrico
2010/6/3 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 30 May 2010 22:43:54 +0400, Eugene wrote:
Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary.
(this is also a reply to Dimitar)
Well, then it's not a big deal to only save_dialog_prefs() after the Preferences dialog is closed and save everything but dialog prefs (UI prefs, session etc.) on exit. That is logical and will solve the problem.
Sounds ok to me. But I didn't have a look at the code to find maybe some potential problems with such a change.
Okay. Just for clarity, the discussion about this topic has moved to a new thread http://lists.uvena.de/geany-devel/2010-May/002358.html. Dimitar and Lex have already posted there some patches.
Oops, sorry. I still didn't manage to follow the thread. It's currently way too time-consuming and also, as you know, I'm not such a big fan of this multiple instance stuff anyway. Geany was never meant to work like this.
Yep, and I wasn't interested in multi instance either until I realised that it allows me to have Geany on multiple screens, I do lot of switching back and forth between .hpp and .cpp files so showing them both would be a *big* help. Helping Eugene and Ditmar get a few wrinkles out of the multiple instance issues (which are mostly exposed by the session management stuff) is easier, no way easier, than making Geany do multiple windows.
Anyway, I'll concentrate on the upcoming release for now and read and reply in the mentioned thread later (hopefully still this weekend).
Correct prioritisation, 0.19 is safe enough (decided after much discussion :), although there are some patches which should go on 0.20, or merge one of the sm implementations each of which contains them.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 04.06.2010 03:27, schrieb Lex Trotman:
Yep, and I wasn't interested in multi instance either until I realised that it allows me to have Geany on multiple screens, I do lot of switching back and forth between .hpp and .cpp files so showing them both would be a*big* help.
How about a proper split edit plugin then? :)
Best regards.
On 10 June 2010 07:50, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 04.06.2010 03:27, schrieb Lex Trotman:
Yep, and I wasn't interested in multi instance either until I realised that it allows me to have Geany on multiple screens, I do lot of switching back and forth between .hpp and .cpp files so showing them both would be a *big* help.
How about a proper split edit plugin then? :)
Multi window editing is the "right" way to do it, but...
Unfortunately scintilla doesn't have a model view paradigm so you have to replay all changes if the same file is visible in two windows. Recent scintilla discussions were not encouraging on the effort required.
Also most of Geany isn't reentrant (eg much of it depends on a global view of current document, project, etc) so there will need to be changes to fix that and to support multiple projects.
But of course don't let that stop you :)
Cheers Lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 19 May 2010 22:13:40 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Or, as another option, we can remove automatic saving of preferences when closing.
I second that.
As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it?
If you think about not saving the configuration at all... The recent files/projects, the current project name, and (depending on the options) the file list still need to be saved. Which is easy to do, but won't solve the race condition.
(BTW, I thought that the Apply button in the Preferences dialog only applies the options temporarily, but it saves them.)
On Sat, 27 Feb 2010 09:05:12 +1100% Lex Trotman elextr@gmail.com wrote:
As I implied in my comment on another message, my use case was to have the filemanager programmed to start a new instance if I double click to look at a file so it doesn't interfere with my "main" instance. I know the socket system was intended to cause exactly the opposite but I've always been a contrary sorta person ;-)
It seems to me that there should be some way (maybe specific to a particular filemanager) to define command-line arguments for a command used to open files. Thus, you can set "geany -i" instead of "geany". The only problem is to discover that way (after you know it indeed exists).
Best regards, Eugene.
On Fri, 26 Feb 2010 15:15:02 +0000, Nick wrote:
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Perhaps without clearly answering you, here's my non-technical thoughts:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
I completely agree here. As said in another reply, file locks/semaphores are most pobably overkill here. Just make the first instance the master (by definition) and this instance is the only one which writes the config. All other instances may read but must not write. This is the easy implementation but also the most logical to me, more logical than 'last instance wins' especially in terms of closing multiple instances on system logout where 'last' is quite randomly as anyone said in another reply. If the master setting works correctly, we don't need to fiddle with semaphores, they would be only an additional tool to enforce the master instance but IMO it's not worth.
Regards, Enrico
2010/3/1 Enrico Tröger enrico.troeger@uvena.de
On Fri, 26 Feb 2010 15:15:02 +0000, Nick wrote:
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Perhaps without clearly answering you, here's my non-technical thoughts:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
I completely agree here. As said in another reply, file locks/semaphores are most pobably overkill here. Just make the first instance the master (by definition) and this instance is the only one which writes the config. All other instances may read but must not write.
Just to check my understanding is that -i means run a whole new Geany and don't create or talk to the socket?
If so, can I suggest its the first instance started WITHOUT -i that becomes the master, ie the one that sets up the socket. As I understand it, thats the one that all files opened by Geany run without -i will show in.
Otherwise the first Geany is effectively ignoring the -i command and is setting up the socket?
Makes it easy, (for users and code) if run with -i = don't save config.
Cheers Lex
This is the easy implementation but also the most logical to me, more logical than 'last instance wins' especially in terms of closing multiple instances on system logout where 'last' is quite randomly as anyone said in another reply. If the master setting works correctly, we don't need to fiddle with semaphores, they would be only an additional tool to enforce the master instance but IMO it's not worth.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 1 Mar 2010 08:21:43 +1100, Lex wrote:
2010/3/1 Enrico Tröger enrico.troeger@uvena.de
On Fri, 26 Feb 2010 15:15:02 +0000, Nick wrote:
On Wed, 24 Feb 2010 12:04:20 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Perhaps without clearly answering you, here's my non-technical thoughts:
To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools->Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings.
I completely agree here. As said in another reply, file locks/semaphores are most pobably overkill here. Just make the first instance the master (by definition) and this instance is the only one which writes the config. All other instances may read but must not write.
Just to check my understanding is that -i means run a whole new Geany and don't create or talk to the socket?
If so, can I suggest its the first instance started WITHOUT -i that becomes the master, ie the one that sets up the socket. As I understand it, thats the one that all files opened by Geany run without -i will show in.
Otherwise the first Geany is effectively ignoring the -i command and is setting up the socket?
Makes it easy, (for users and code) if run with -i = don't save config.
Sounds useful. I didn't check the code but IIRC -i do ignore the socket part if there is one. I'm not exactly sure whether it does or does not create a new socket if there is no running instance. Ideally, it should really ignore all socket stuff and don't save settings. This would be what you suggest and what would be most consistent, I think.
Regards, Enrico
Am Mittwoch, den 24.02.2010, 12:04 +0300 schrieb Eugene Arshinov:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
There always are elegant solutions to solve a problem and maybe solutions which are not that elegant but would work too. If I understood you right, the first one would be the one more elegant?
I'd always prefer an elegant solution over one which is not that elegant. :)
Regards, Dominic
On Sat, 27 Feb 2010 17:49:06 +0100, Dominic wrote:
Am Mittwoch, den 24.02.2010, 12:04 +0300 schrieb Eugene Arshinov:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
There always are elegant solutions to solve a problem and maybe solutions which are not that elegant but would work too. If I understood you right, the first one would be the one more elegant?
I'd always prefer an elegant solution over one which is not that elegant. :)
IMO file locks/metaphors are clearly overkill here and are probably hard to realise portable (maybe I'm wrong here, I didn't work much with those so far).
Regards, Enrico
On Sun, 28 Feb 2010 14:20:08 +0100, Enrico wrote:
On Sat, 27 Feb 2010 17:49:06 +0100, Dominic wrote:
Am Mittwoch, den 24.02.2010, 12:04 +0300 schrieb Eugene Arshinov:
Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
There always are elegant solutions to solve a problem and maybe solutions which are not that elegant but would work too. If I understood you right, the first one would be the one more elegant?
I'd always prefer an elegant solution over one which is not that elegant. :)
IMO file locks/metaphors are clearly overkill here and are probably
s/metaphors/semaphores/
:)
Regards, Enrico