On Fri, 4 Jun 2010 11:48:22 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Thu, 3 Jun 2010 19:14:39 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup.
Interesting. It's worth debugging sm_set_runtime_props() with gdb step-by-step and see when session is killed.
That didn't work, the session was killed asynchronously. But while trying to trace geany with nemiver, the session remained stable - only geany-4968 was closed, and a new geany was started, as if the SM tried to clone or restart it (hint restart now?), using the program name from the legacy SM protocol.
Anyway, commenting out SmcSetProperties() for _both_ the restart and clone commands resulted in a stable running Geany. So there's probably something wrong with their prop values.
Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though.
Yes, a --no-session will do. You should mark it as non-persistent anyway, otherwise a geany once started with --no-session will come empty (no files open) each time the session is restored.
To speak truth, when I wrote this code I didn't think about several main instances. I still does not understand why they are needed. Lex explained me why opening one project in several instances can be useful, but opening several main instances seems to be even more crazy stuff :)
I have two main instances running (with sm) since may-19: one on desktop 1 with BDF/FNA files, and another on desktop 2 with geany source files. My file manager is set to open bdf/fna with geany socket file "desktop1", and [ch] files with "desktop2".
But it'll be better to write a short script that runs geany with socket "desktop<current>". That's how nedit worked, very convinient.