Hi, all,
This is an alternate implementation of Eugene's X11 session support. The main difference is that the state each running Geany is saved into a separate temporary Geany configuration file.
Each Geany is restored exactly it was before the session was closed, including open files, options (including applied but unsaved), per-document options (even if no project file is open) etc.
There are no races when saving geany.conf, it's not saved at all. If you want to save the options, so that the next Geany will use them, just go to the Geany you want the options from and save them, exactly as you would do before the session was closed.
Should there be "main" and "option-saving" instances, which ones, and how should they differ from the "secondary" instances? As Eugene pointed out, this is not related to the session management, at least with this SM implementation.
The patch applies against the latest svn-4933. Of course, it should not be included in 0.19, I only finished it today. Some parts of Eugene's SM were reverted, since they were not required.
-- E-ragds: Jimmy
On Wed, 19 May 2010 14:17:52 +0300, Dimitar wrote:
Hi, all,
This is an alternate implementation of Eugene's X11 session support. The main difference is that the state each running Geany is saved into a separate temporary Geany configuration file.
Each Geany is restored exactly it was before the session was closed, including open files, options (including applied but unsaved), per-document options (even if no project file is open) etc.
There are no races when saving geany.conf, it's not saved at all. If you want to save the options, so that the next Geany will use them, just go to the Geany you want the options from and save them, exactly as you would do before the session was closed.
Should there be "main" and "option-saving" instances, which ones, and how should they differ from the "secondary" instances? As Eugene pointed out, this is not related to the session management, at least with this SM implementation.
Now we have two alternating SM implementations? Why?
As you say, the configuration save problem isn't strictly related to SM and might be solved separately. Though I'm not yet sure what's the best way to solve this. I think I still like something close to the current behaviour: the main instance (i.e. the first opened one) is master over the config file. And any other instances are ignored.
I guess the main problem here is that Geany was never designed to be used as multiple window editor, and IMO it shouldn't be changed to be one.
Regards, Enrico
On Wed, 19 May 2010 23:15:40 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Each Geany is restored exactly it was before the session was closed, including open files, options (including applied but unsaved), per-document options (even if no project file is open) etc.
Now we have two alternating SM implementations? Why?
Because I wanted the Geany-s state to be restored more precisely. The only way to do that were separate .conf files, which eliminates the race condition as well.
Also, the alternate implementation doesn't require a --project option - using argv[1] is the easiest wat to open a geany project file from the file manager.
I think I still like something close to the current behaviour: the main instance (i.e. the first opened one) is master over the config file.
This behaviour is still in the future. Unless I'm missing something, if you start geany twice with different sockets, there will be two "main" instances using the same configuration file.
Eugene's original implementation requires main/secondary instances; this one does not.
I guess the main problem here is that Geany was never designed to be used as multiple window editor, and IMO it shouldn't be changed to be one.
Indeed, so I save each Geany completely separately. Since this is more compliant with the current (as in "currently implemented") behaviour, it's also ~1/3 shorter.
On 20 May 2010 17:59, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Wed, 19 May 2010 23:15:40 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Each Geany is restored exactly it was before the session was closed, including open files, options (including applied but unsaved), per-document options (even if no project file is open) etc.
Now we have two alternating SM implementations? Why?
Because I wanted the Geany-s state to be restored more precisely. The only way to do that were separate .conf files, which eliminates the race condition as well.
Also, the alternate implementation doesn't require a --project option
- using argv[1] is the easiest wat to open a geany project file from
the file manager.
I think I still like something close to the current behaviour: the main instance (i.e. the first opened one) is master over the config file.
This behaviour is still in the future. Unless I'm missing something, if you start geany twice with different sockets, there will be two "main" instances using the same configuration file.
Eugene's original implementation requires main/secondary instances; this one does not.
I guess the main problem here is that Geany was never designed to be used as multiple window editor, and IMO it shouldn't be changed to be one.
Indeed, so I save each Geany completely separately. Since this is more compliant with the current (as in "currently implemented") behaviour, it's also ~1/3 shorter.
Maybe I missed something, but what happens to configuration under this plan
when instances are manually closed and re-opened?
Which of the .conf files is used when the first is manually opened, the second is manually opened etc.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 20 May 2010 19:05:24 +1000 Lex Trotman elextr@gmail.com wrote:
Maybe I missed something, but what happens to configuration under this plan when instances are manually closed and re-opened?
Which of the .conf files is used when the first is manually opened, the second is manually opened etc.
The x11 session .conf files are used only temporarily when a geany is stopped/started by the session manager. Everything else remains as is.
Strictly speaking, when a program registers itself as a x11 session client, the SM immediately sends it a SmSaveLocal; and if your SM supports a list of sessions, it sends a SmSaveLocal or SmSaveBoth when the user explicitly saves a session. Of course, these use the x11 session .conf files too.
-- E-gards: Jimmy
On 20 May 2010 19:46, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Thu, 20 May 2010 19:05:24 +1000 Lex Trotman elextr@gmail.com wrote:
Maybe I missed something, but what happens to configuration under this
plan
when instances are manually closed and re-opened?
Which of the .conf files is used when the first is manually opened, the second is manually opened etc.
The x11 session .conf files are used only temporarily when a geany is stopped/started by the session manager. Everything else remains as is.
Strictly speaking, when a program registers itself as a x11 session client, the SM immediately sends it a SmSaveLocal; and if your SM supports a list of sessions, it sends a SmSaveLocal or SmSaveBoth when the user explicitly saves a session. Of course, these use the x11 session .conf files too.
So I take that to mean the session of the first will be used??
But don't you still have a race condition on Geany's config file when several Geanys close at once??
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 20 May 2010 19:50:49 +1000 Lex Trotman elextr@gmail.com wrote:
The x11 session .conf files are used only temporarily when a geany is stopped/started by the session manager. Everything else remains as is.
So I take that to mean the session of the first will be used??
But don't you still have a race condition on Geany's config file when several Geanys close at once??
No, no. The .geany files names used include the SM client id, which is unique for each program (normally UUID-s).
The whole idea is that each Geany saves itself, without any relation to the other running Geany-s.
-- E-gards: Jimmy
On 20 May 2010 20:16, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Thu, 20 May 2010 19:50:49 +1000 Lex Trotman elextr@gmail.com wrote:
The x11 session .conf files are used only temporarily when a geany is stopped/started by the session manager. Everything else remains as is.
So I take that to mean the session of the first will be used??
But don't you still have a race condition on Geany's config file when several Geanys close at once??
No, no. The .geany files names used include the SM client id, which is unique for each program (normally UUID-s).
The whole idea is that each Geany saves itself, without any relation to the other running Geany-s.
Ok, I see great, so when the X session re-starts all the Geanys re-load
ok, but then what happens if I shut Geany instances down manually?
Somewhere a non-session geany.conf must be written, does the last shut down win or what?
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 20 May 2010 20:32:37 +1000 Lex Trotman elextr@gmail.com wrote:
No, no. The .geany files names used include the SM client id, which is unique for each program (normally UUID-s).
small mistake: s/.geany files/.conf files/
The whole idea is that each Geany saves itself, without any relation to the other running Geany-s.
Ok, I see great, so when the X session re-starts all the Geanys re-load ok, but then what happens if I shut Geany instances down manually?
Somewhere a non-session geany.conf must be written, does the last shut down win or what?
When you stop a geany with [x] or File -> Quit, it's no more part of the x11 session, so the SM executes it's discard command, which removes it's geany-smclientid-conf file.
Aside from that, the standard geany quit is unaltered. It does what it ever did.
On 20 May 2010 20:50, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Thu, 20 May 2010 20:32:37 +1000 Lex Trotman elextr@gmail.com wrote:
No, no. The .geany files names used include the SM client id, which is unique for each program (normally UUID-s).
small mistake: s/.geany files/.conf files/
The whole idea is that each Geany saves itself, without any relation to the other running Geany-s.
Ok, I see great, so when the X session re-starts all the Geanys re-load ok, but then what happens if I shut Geany instances down manually?
Somewhere a non-session geany.conf must be written, does the last shut
down
win or what?
When you stop a geany with [x] or File -> Quit, it's no more part of the x11 session, so the SM executes it's discard command, which removes it's geany-smclientid-conf file.
Aside from that, the standard geany quit is unaltered. It does what it ever did.
Ok, in Eugenes version only one Geany, the first one run, will save the
Geany.conf so you know what you will get next time you start a Geany, does your version allow all Geanys to save their geany.conf, ie last closed "wins"?
Your session management feature sounds great, lets each instance of Geany set the config it wants, but I'm just trying to understand how it works with the rest of Geany and when I change what instances are running.
I'm not really fond of last wins, though it is common on Unix.
Oh yes how does your patch work if the X sm libs are not available (eg Windows), can we set a symbol to compile without it?
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 20 May 2010 21:23:49 +1000 Lex Trotman elextr@gmail.com wrote:
Aside from that, the standard geany quit is unaltered. It does what it ever did.
Ok, in Eugenes version only one Geany, the first one run, will save the Geany.conf so you know what you will get next time you start a Geany, does your version allow all Geanys to save their geany.conf, ie last closed "wins"?
Nobody "wins" or "loses". The sm-geany-quit (which is actually broken into 3 parts, that's how the sm works) does not touch the standard geany.conf at all, and it remains the way it was before the session was restarted.
Each geany saves it's own geany-smclientid.conf file only, with it's own preferences, file list etc. And of course, it reads it's own .conf file only when started by the SM.
(and when started manually, it performs a normal startup, if that's what you'll going to ask next :)
Your session management feature sounds great, lets each instance of Geany set the config it wants, but I'm just trying to understand how it works with the rest of Geany and when I change what instances are running.
Generally, it works more like "suspend-resume", not like "close all geany-s and start them again".
The goal is to continue as if your "working session" was never interrupted. It is the user who should save geany.conf IMO, be it by using "Edit -> Preferences" or whatever, while the session manager should just reproduce all running geany-s as closely as possible.
Oh yes how does your patch work if the X sm libs are not available (eg Windows), can we set a symbol to compile without it?
Yes, that's derived from the Eugene's original implementation (#ifdef HAVE_LIBSM).
On 20 May 2010 22:33, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Thu, 20 May 2010 21:23:49 +1000 Lex Trotman elextr@gmail.com wrote:
Aside from that, the standard geany quit is unaltered. It does what it ever did.
Ok, in Eugenes version only one Geany, the first one run, will save the Geany.conf so you know what you will get next time you start a Geany,
does
your version allow all Geanys to save their geany.conf, ie last closed "wins"?
Sorry I wasn't clear, I was talking about closing instances manually, I understand how the sm works, I am trying to work out what behaviour the user sees when closing instances manually.
Nobody "wins" or "loses". The sm-geany-quit (which is actually broken into 3 parts, that's how the sm works) does not touch the standard geany.conf at all, and it remains the way it was before the session was restarted.
Each geany saves it's own geany-smclientid.conf file only, with it's own preferences, file list etc. And of course, it reads it's own .conf file only when started by the SM.
(and when started manually, it performs a normal startup, if that's what you'll going to ask next :)
Your session management feature sounds great, lets each instance of Geany set the config it wants, but I'm just trying to understand how it works
with
the rest of Geany and when I change what instances are running.
Generally, it works more like "suspend-resume", not like "close all geany-s and start them again".
The goal is to continue as if your "working session" was never interrupted. It is the user who should save geany.conf IMO, be it by using "Edit -> Preferences" or whatever, while the session manager should just reproduce all running geany-s as closely as possible.
As I said above I'm no longer interested in what happens when a session is continued, what happens when I close things manually, and then start new instances of Geany.
Clearly these don't use sm specific versions of .conf, but what version of the Geany.conf will they see, when is it saved? When some Geanys are still running and I start another?
When I close one or more and then start another?
Oh yes how does your patch work if the X sm libs are not available (eg Windows), can we set a symbol to compile without it?
Yes, that's derived from the Eugene's original implementation (#ifdef HAVE_LIBSM).
Ok, fine :-)
I'm getting tired and grumpy, I'll see your reply tomorrow, apologies for being a bit slow at this time.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 20 May 2010 23:05:59 +1000 Lex Trotman elextr@gmail.com wrote:
[...] As I said above I'm no longer interested in what happens when a session is continued, what happens when I close things manually, and then start new instances of Geany. [...] Clearly these don't use sm specific versions of .conf, but what version of the Geany.conf will they see, when is it saved? When some Geanys are still running and I start another?
To cut it down: this patch does session support only, the normal start/close of Geany is completely unaffected. The users will see whatever geany.conf options they have saved, whenever they have saved them, be it even before a session restart.
The "multiple instance save-settings" problem, if any, is not related to this sm implementation.
Comments from "Multiple instances of Geany issues" thread...
I think so too, and my X sm is raceless, so..
AFAICT only partly raceless, please point me to where I've misunderstood, I'm not that great at reading diffs.
My understanding is:
For Geany.conf its raceless because when Geany is closed by signal it doesn't save and when closed by session manager it saves a different file for each instance.
For projects I can't see where it saves different versions for each instance on a session manager save so there can be a race here.
For user files, if the session manager allows user interaction then the standard save file prompt will occur, serialising saves through the user, if no interaction is allowed then no saves are performed.
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.
also from other thread.
we'd better drop the locking/renaming at all, it has too many potential problems.
If the races I noted above are wrong or fixed then I agree, otherwise its still needed.
If its still needed, what problems do you see?? On filesystems and platforms where it works it will remove races, on platforms where it doesn't work things won't be any worse than they are without it.
Cheers Lex
On Mon, 24 May 2010 14:38:53 +1000 Lex Trotman elextr@gmail.com wrote:
Comments from "Multiple instances of Geany issues" thread...
I think so too, and my X sm is raceless, so..
AFAICT only partly raceless, please point me to where I've misunderstood, I'm not that great at reading diffs.
My understanding is:
[...]
For projects I can't see where it saves different versions for each instance on a session manager save so there can be a race here.
It doesn't save the projects at all. A project consists of: - Settings - these are saved by the Project -> Properties function. - List of open files - saved into geany-smclientid.conf.
Since my goal is to continue a restarted session as if it was never interrupted (well, with the exception of the editor files), not saving the project is the right thing to do.
[...]
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.
Yes, if 2+ sessions have modified the commands for the same file type... Which brings questions belonging to the save settings thread, so I'll answer there.
If locking still needed, what problems do you see?? On filesystems and platforms where it works it will remove races, on platforms where it doesn't work things won't be any worse than they are without it.
Perhaps I'm too wary. The only case I can think about is a network directory configured so that the files are writable, but not deletable (a reasonable precaution for a shared directory). In such a case, O_EXCL will leave stalled files, and rename will fail too.
Under *ix, the configuration directory should have deletable files anyway, otherwise the socket/symlink will not work properly.
-- E-gards: Jimmy
On 24 May 2010 18:16, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Mon, 24 May 2010 14:38:53 +1000 Lex Trotman elextr@gmail.com wrote:
Comments from "Multiple instances of Geany issues" thread...
I think so too, and my X sm is raceless, so..
AFAICT only partly raceless, please point me to where I've misunderstood, I'm not that great at reading diffs.
My understanding is:
[...]
For projects I can't see where it saves different versions for each instance on a session manager save so there can be a race here.
It doesn't save the projects at all. A project consists of:
- Settings - these are saved by the Project -> Properties function.
- List of open files - saved into geany-smclientid.conf.
Since my goal is to continue a restarted session as if it was never interrupted (well, with the exception of the editor files), not saving the project is the right thing to do.
Ok, that sounds like it will work.
[...]
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.
Yes, if 2+ sessions have modified the commands for the same file type... Which brings questions belonging to the save settings thread, so I'll answer there.
If locking still needed, what problems do you see?? On filesystems and platforms where it works it will remove races, on platforms where it doesn't work things won't be any worse than they are without it.
Perhaps I'm too wary. The only case I can think about is a network directory configured so that the files are writable, but not deletable (a reasonable precaution for a shared directory). In such a case, O_EXCL will leave stalled files, and rename will fail too.
Under *ix, the configuration directory should have deletable files anyway, otherwise the socket/symlink will not work properly.
So lets fix filetypes IAW your other reply and forget the locks.
Cheers Lex
PS I hope noone decides to catch SIGHUP and start saving things :-(
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 19 May 2010 14:17:52 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
Hi, all,
This is an alternate implementation of Eugene's X11 session support. The main difference is that the state each running Geany is saved into a separate temporary Geany configuration file.
Each Geany is restored exactly it was before the session was closed, including open files, options (including applied but unsaved), per-document options (even if no project file is open) etc.
There are no races when saving geany.conf, it's not saved at all. If you want to save the options, so that the next Geany will use them, just go to the Geany you want the options from and save them, exactly as you would do before the session was closed.
Should there be "main" and "option-saving" instances, which ones, and how should they differ from the "secondary" instances? As Eugene pointed out, this is not related to the session management, at least with this SM implementation.
The patch applies against the latest svn-4933. Of course, it should not be included in 0.19, I only finished it today. Some parts of Eugene's SM were reverted, since they were not required.
Hi. Several questions and suggestions here :)
1. On my system your version do not automatically remove temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand.
2. Is tm_get_real_path() really necessary in utils_option_entry_reverse_parse() for command-line options of G_OPTION_ARG_FILENAME type? I saw tm_get_real_path() is called from some other places in code, but have no idea why it's needed.
3. When specifying SmProgram value, you should properly handle the case when argv[0] does not contain path (i.e., when Geany is resolved using PATH). If argv[0] does not contain path, tm_get_real_path() returns NULL for it on my system, causing a segfault.
Best regards, Eugene.
On Wed, 30 Jun 2010 12:09:43 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 19 May 2010 14:17:52 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
The patch applies against the latest svn-4933. Of course, it should not be included in 0.19, I only finished it today. Some parts of Eugene's SM were reverted, since they were not required.
Hi. Several questions and suggestions here :)
- On my system your version do not automatically remove temporary
SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand.
They are removed when a program ceases to be part of the session (i.e. when you close an instance), not on session restart or something.
- Is tm_get_real_path() really necessary in
utils_option_entry_reverse_parse() for command-line options of G_OPTION_ARG_FILENAME type? I saw tm_get_real_path() is called from some other places in code, but have no idea why it's needed.
That was not only unneeded, but buggy - the config directory and the socket file arguments could be non-existent. I removed it 10 days ago.
- When specifying SmProgram value, you should properly handle the case
when argv[0] does not contain path (i.e., when Geany is resolved using PATH). If argv[0] does not contain path, tm_get_real_path() returns NULL for it on my system, causing a segfault.
That was also fixed, and the description of tm_get_real_path() has been changed - it said that "a reasonable guess is returned even if the file does not exist". :-)
(On that note, I don't think it's necessary for you to try guessing the absolute name of args[0], every program I've seen just stores argv[0] directly.)
There are some other fixes, I can send a patch against 5064 if you want.
On Wed, 30 Jun 2010 21:48:15 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 30 Jun 2010 12:09:43 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 19 May 2010 14:17:52 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
The patch applies against the latest svn-4933. Of course, it should not be included in 0.19, I only finished it today. Some parts of Eugene's SM were reverted, since they were not required.
Hi. Several questions and suggestions here :)
- On my system your version do not automatically remove temporary
SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand.
They are removed when a program ceases to be part of the session (i.e. when you close an instance), not on session restart or something.
But even if I open Geany and immediately close it, its temporary file is still there. I just checked out that the file still exists even after I logout and login again (i.e., after GNOME session manager is restarted).
- Is tm_get_real_path() really necessary in
utils_option_entry_reverse_parse() for command-line options of G_OPTION_ARG_FILENAME type? I saw tm_get_real_path() is called from some other places in code, but have no idea why it's needed.
That was not only unneeded, but buggy - the config directory and the socket file arguments could be non-existent. I removed it 10 days ago.
- When specifying SmProgram value, you should properly handle the
case when argv[0] does not contain path (i.e., when Geany is resolved using PATH). If argv[0] does not contain path, tm_get_real_path() returns NULL for it on my system, causing a segfault.
That was also fixed, and the description of tm_get_real_path() has been changed - it said that "a reasonable guess is returned even if the file does not exist". :-)
Okay.
(On that note, I don't think it's necessary for you to try guessing the absolute name of args[0], every program I've seen just stores argv[0] directly.)
I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still.
There are some other fixes, I can send a patch against 5064 if you want.
Yes, that would be good. I have an idea of combining your SM implementation with my sm branch (you know the branch now contains plenty of things apart of SM, e.g. changes in command-line handling, Geany session management, recent settings-saving patches, my "proof of concept" method of merging recent lists etc.). That would require some work, but I think it's worth it. If I finally do it, I'll send here resulting patch(es).
Best regards, Eugene.
On Thu, 1 Jul 2010 11:51:18 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 30 Jun 2010 21:48:15 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
- On my system your version do not automatically remove temporary
SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand.
They are removed when a program ceases to be part of the session (i.e. when you close an instance), not on session restart or something.
But even if I open Geany and immediately close it, its temporary file is still there. I just checked out that the file still exists even after I logout and login again (i.e., after GNOME session manager is restarted).
Well, under xfce-sm they are deleted as soon as the geany instance is closed (xfce has some other bugs though). With GNOME, a lot of the session management is implemented in it's session client library. The best and most compliant XSM is that of KDE4.
And easier way to test than installing KDE is to temporarily disable the GNOME SM and use xsm(1). It's not suitable for practical work, but should be enough to try the creation/deletion of the .conf files.
(On that note, I don't think it's necessary for you to try guessing the absolute name of args[0], every program I've seen just stores argv[0] directly.)
I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still.
With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support, especially for non-gnome programs, and always had. Instead of fixing it, they finally replaced XSMP with a D-Bus based protocol at the end of 2008. So if you feel like writing support for it... I do not.
There are some other fixes, I can send a patch against 5064 if you want.
Yes, that would be good. I have an idea of combining your SM implementation with my sm branch (you know the branch now contains plenty of things apart of SM, e.g. changes in command-line handling, Geany session management, [...] If I finally do it, I'll send here resulting patch(es).
Attached. To prevent an unlikely race condition, the "Build -> Set build commands" settings should be saved on OK response, instead of when exiting Geany, but I believe your sm branch includes that.
On Thu, 1 Jul 2010 19:48:18 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 1 Jul 2010 11:51:18 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 30 Jun 2010 21:48:15 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
- On my system your version do not automatically remove
temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand.
They are removed when a program ceases to be part of the session (i.e. when you close an instance), not on session restart or something.
But even if I open Geany and immediately close it, its temporary file is still there. I just checked out that the file still exists even after I logout and login again (i.e., after GNOME session manager is restarted).
Well, under xfce-sm they are deleted as soon as the geany instance is closed (xfce has some other bugs though). With GNOME, a lot of the session management is implemented in it's session client library. The best and most compliant XSM is that of KDE4.
And easier way to test than installing KDE is to temporarily disable the GNOME SM and use xsm(1). It's not suitable for practical work, but should be enough to try the creation/deletion of the .conf files.
Thanks, I'll try that.
(On that note, I don't think it's necessary for you to try guessing the absolute name of args[0], every program I've seen just stores argv[0] directly.)
I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still.
With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support, especially for non-gnome programs, and always had. Instead of fixing it, they finally replaced XSMP with a D-Bus based protocol at the end of 2008.
Yes, I heard about it.
So if you feel like writing support for it... I do not.
No, I don't like it, but there are some GNOME users out there :)
There are some other fixes, I can send a patch against 5064 if you want.
Yes, that would be good. I have an idea of combining your SM implementation with my sm branch (you know the branch now contains plenty of things apart of SM, e.g. changes in command-line handling, Geany session management, [...] If I finally do it, I'll send here resulting patch(es).
Attached. To prevent an unlikely race condition, the "Build -> Set build commands" settings should be saved on OK response, instead of when exiting Geany, but I believe your sm branch includes that.
Okay, thanks.
On Fri, 2 Jul 2010 13:20:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
- On my system your version do not automatically remove
temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand.
I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still.
With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support [...]
So if you feel like writing support for it... I do not.
No, I don't like it, but there are some GNOME users out there :)
Well, I guess we can somehow check if Geany is running under GNOME, and if so, delete the SM-file on normal (non-session) Geany quit. And place a note in the documentation: "under GNOME, specific versions of Geany should be run with absolute path if you want them restored on the next restart".
Since you are running GNOME, can you look at the environment variables for something specific?
On Sun, 4 Jul 2010 14:07:27 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 2 Jul 2010 13:20:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
- On my system your version do not automatically remove
temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand.
I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still.
With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support [...]
So if you feel like writing support for it... I do not.
No, I don't like it, but there are some GNOME users out there :)
Well, I guess we can somehow check if Geany is running under GNOME, and if so, delete the SM-file on normal (non-session) Geany quit.
We can always delete the file ourselves. Seems that it won't be harmful for "compliant" session managers.
And place a note in the documentation: "under GNOME, specific versions of Geany should be run with absolute path if you want them restored on the next restart".
I think it's better to have 5 or so additional lines of code than to leave this problem for end users.
Since you are running GNOME, can you look at the environment variables for something specific?
Just looked at the output of `set' command. Can see nothing GNOME-specific there.
On Sun, 4 Jul 2010 15:20:12 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sun, 4 Jul 2010 14:07:27 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 2 Jul 2010 13:20:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
> 1. On my system your version do not automatically remove > temporary SM-related session files. Is it supposed to do > so? I saw that you specified DiscardCommand.
I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still.
With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support [...]
So if you feel like writing support for it... I do not.
No, I don't like it, but there are some GNOME users out there :)
Well, I guess we can somehow check if Geany is running under GNOME, and if so, delete the SM-file on normal (non-session) Geany quit.
We can always delete the file ourselves. Seems that it won't be harmful for "compliant" session managers.
The XSMP does not specify when the SmDiscardCommand will/should be executed. For example, what if the user logs out, and only then unchecks "Save this session for future use" or something? Geany will be terminated without any notice, and the discarding remains to the SM. So we'd better do both.
And place a note in the documentation: "under GNOME, specific versions of Geany should be run with absolute path if you want them restored on the next restart".
I think it's better to have 5 or so additional lines of code than to leave this problem for end users.
This is a rare situation, and the executable name can't be determined 100% reliably without using /proc or something (there is no such UNIX API). You can try a few programs from the GNOME Official applications list, and if they simply store argv[0], I think it'll be too much for Geany to do more than that.
On Sun, 4 Jul 2010 15:00:00 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 4 Jul 2010 15:20:12 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sun, 4 Jul 2010 14:07:27 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 2 Jul 2010 13:20:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
> > 1. On my system your version do not automatically remove > > temporary SM-related session files. Is it supposed to > > do so? I saw that you specified DiscardCommand. > I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still.
With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support [...]
So if you feel like writing support for it... I do not.
No, I don't like it, but there are some GNOME users out there :)
Well, I guess we can somehow check if Geany is running under GNOME, and if so, delete the SM-file on normal (non-session) Geany quit.
We can always delete the file ourselves. Seems that it won't be harmful for "compliant" session managers.
The XSMP does not specify when the SmDiscardCommand will/should be executed. For example, what if the user logs out, and only then unchecks "Save this session for future use" or something? Geany will be terminated without any notice, and the discarding remains to the SM. So we'd better do both.
Yes, sorry for being not clear. I meant both specifying SmDiscardCommand and deleting file manually when user closes Geany.
And place a note in the documentation: "under GNOME, specific versions of Geany should be run with absolute path if you want them restored on the next restart".
I think it's better to have 5 or so additional lines of code than to leave this problem for end users.
This is a rare situation, and the executable name can't be determined 100% reliably without using /proc or something (there is no such UNIX API). You can try a few programs from the GNOME Official applications list, and if they simply store argv[0], I think it'll be too much for Geany to do more than that.
No, we need to look for absolute path if and only if Geany is run using relative path. When Geany is run either using absolute path or without any path at all, we can leave the path as is. GNOME's session manager does not work only with relative paths. Getting absolute path from relative to current directory is ~5 lines without any hacks.
On Sun, 4 Jul 2010 17:24:49 +0400 Eugene Arshinov earshinov@gmail.com wrote:
No, we need to look for absolute path if and only if Geany is run using relative path.
Why not, really.
Getting absolute path from relative to current directory is ~5 lines without any hacks.
Even less - tm_get_real_path() is our friend here, it both expands the path and checks if it exists.
Updated version attached.
On Fri, 8 Oct 2010 06:05:11 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sat, 2 Oct 2010 10:56:19 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Eugene, if you're going to combine the X SM implementatons someday, using the "alternate" save/restore instance, be sure to revert this change (or find a workaround, but I don't think it's worth).
Thanks much for info, I'll take it into account.
Something worse: an "Open files in Geany at the same workspace", no matter how implemented, will be problematic for your current session save/restore. main_save() saves geany.conf for the primary instance, but there will be several primaries - one per desktop...
You can switch to "alternate", or lock/unlock geany.conf, or traverse the sockets. But traversing seems unreliable, a socket may be checked shortly before or after an instance dies.
On Fri, 8 Oct 2010 19:55:28 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 8 Oct 2010 06:05:11 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sat, 2 Oct 2010 10:56:19 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Eugene, if you're going to combine the X SM implementatons someday, using the "alternate" save/restore instance, be sure to revert this change (or find a workaround, but I don't think it's worth).
Thanks much for info, I'll take it into account.
Something worse: an "Open files in Geany at the same workspace", no matter how implemented, will be problematic for your current session save/restore. main_save() saves geany.conf for the primary instance, but there will be several primaries - one per desktop...
You can switch to "alternate", or lock/unlock geany.conf, or traverse the sockets. But traversing seems unreliable, a socket may be checked shortly before or after an instance dies.
Actually I would prefer switching to alternate :-) But currently I don't have free time to work on this, so SM branch will stay outdated for a while…
Best regards, Eugene.