Hi,
The following bug on sf.net:
http://sourceforge.net/tracker/?func=detail&aid=2896027&group_id=153...
states:
If I work, I have often open more projects on more workspaces. And I have more runned Geany, too. But if I want open some file, it is open in window of Geany which was open first. I would like to open file in Geany which is at the same workspaces.
I would also like this functionality, but the bug has been closed, without an explanation.
I've had a look at the geany sources, and I think I know how to add this functionality. Would a clean patch for this be accepted?
Cheers, Erik
Erik de Castro Lopo wrote:
I would also like this functionality, but the bug has been closed, without an explanation.
Ooops, found the explanation:
http://lists.uvena.de/pipermail/geany-devel/2009-November/001567.html
I still think this functionality can be improved on to do the right thing for most people most of the time.
Erik
Erik de Castro Lopo wrote:
I still think this functionality can be improved on to do the right thing for most people most of the time.
Ah, its in the TODO list anyway:
o (per-workspace instances with socket support?)
Since I have already figured out the basic mechanics of how to do this using nothing more than GTK/GDK and X11 libs, I'll roll a patch and send it in.
Cheers, Erik
On 4 August 2010 11:05, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Erik de Castro Lopo wrote:
I still think this functionality can be improved on to do the right thing for most people most of the time.
Ah, its in the TODO list anyway:
o (per-workspace instances with socket support?)
Since I have already figured out the basic mechanics of how to do this using nothing more than GTK/GDK and X11 libs, I'll roll a patch and send it in.
If it won't work on windows, remember to make your patch remove itself when compiled on windows
Cheers Lex
Cheers, Erik
--
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman wrote:
If it won't work on windows, remember to make your patch remove itself when compiled on windows
Windows? Yeah, I've heard of that. There's also this thing called Mac that some people like :-).
I'll keep that in mind.
Cheers, Erik
Erik de Castro Lopo wrote:
Erik de Castro Lopo wrote:
I still think this functionality can be improved on to do the right thing for most people most of the time.
Ah, its in the TODO list anyway:
o (per-workspace instances with socket support?)
Since I have already figured out the basic mechanics of how to do this using nothing more than GTK/GDK and X11 libs, I'll roll a patch and send it in.
I've been running the attached patch for two days now and its worked flawlessly on Debian Testing, Ubuntu Lucid and Ubuntu Hardy.
I've been careful to try and make sure the code compiles on windows and mac, but I haven't tested it. There is code in place for these systems so that if it can't determine the workspace number it just returns a default of 0. This means that windows/mac behaviour will be unchanged after this patch.
Cheers, Erik
On Fri, 6 Aug 2010 09:19:57 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Erik de Castro Lopo wrote:
Erik de Castro Lopo wrote:
I still think this functionality can be improved on to do the right thing for most people most of the time.
Ah, its in the TODO list anyway:
o (per-workspace instances with socket support?)
Since I have already figured out the basic mechanics of how to do this using nothing more than GTK/GDK and X11 libs, I'll roll a patch and send it in.
I've been running the attached patch for two days now and its worked flawlessly on Debian Testing, Ubuntu Lucid and Ubuntu Hardy.
I've been careful to try and make sure the code compiles on windows and mac, but I haven't tested it. There is code in place for these systems so that if it can't determine the workspace number it just returns a default of 0. This means that windows/mac behaviour will be unchanged after this patch.
Thanks for your work on this. From a very brief look the design looks good but I haven't tested it. I'll return to this thread when we've made the 0.19.1 release.
Regards, Nick
Nick Treleaven wrote:
Thanks for your work on this. From a very brief look the design looks good but I haven't tested it.
As I think Dimitar mentioned, windows has named rather than numbered workspaces. It would be relatively trivial to rework my patch so that the function that finds the workspace number instead generates a string for the workspace number.
Let me know if you want this and I'll rejig and resubmit the patch.
I'll return to this thread when we've made the 0.19.1 release.
Cool. Thanks.
Erik
On Thu, 12 Aug 2010 13:30:25 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Thanks for your work on this. From a very brief look the design looks good but I haven't tested it.
As I think Dimitar mentioned, windows has named rather than numbered workspaces. It would be relatively trivial to rework my patch so that the function that finds the workspace number instead generates a string for the workspace number.
Let me know if you want this and I'll rejig and resubmit the patch.
I suppose so. I've never heard of multiple workspaces on Windows other than by non-standard utilities so any links would be appreciated.
Regards, Nick
Nick Treleaven wrote:
I suppose so. I've never heard of multiple workspaces on Windows other than by non-standard utilities so any links would be appreciated.
I haven't used windows for years so I can't help :-).
Erik
On Thu, 12 Aug 2010 12:51:21 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 12 Aug 2010 13:30:25 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Thanks for your work on this. From a very brief look the design looks good but I haven't tested it.
As I think Dimitar mentioned, windows has named rather than numbered workspaces. It would be relatively trivial to rework my patch so that the function that finds the workspace number instead generates a string for the workspace number.
Let me know if you want this and I'll rejig and resubmit the patch.
I suppose so. I've never heard of multiple workspaces on Windows other than by non-standard utilities so any links would be appreciated.
Any NT-system supports "virtual desktops". Win 9x does not.
google site:msdn.microsoft.com Window Station and Desktop Functions, http://technet.microsoft.com/en-us/sysinternals/cc817881.aspx
For example, the login screen is on separate desktop, with a higher level of propection that the regular ones; XP "fast user switching" creates per-user window stations, and desktops within them.
Almost no applications support these. For example, if you run FF on two desktops, the 2nd instance will say "FF is already running" and exit. Windows itself does not handle them very well: Task Manager and the Ctrl-Alt-Del window are always displayed on the initial desktop, but the system does not switch to it, and it looks like nothing happened.
A window can not be moved from one desktop to another. An application can be moved, but only if it has no open windows and active hooks.
On Thu, 12 Aug 2010 16:16:28 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 12 Aug 2010 12:51:21 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 12 Aug 2010 13:30:25 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Thanks for your work on this. From a very brief look the design looks good but I haven't tested it.
As I think Dimitar mentioned, windows has named rather than numbered workspaces. It would be relatively trivial to rework my patch so that the function that finds the workspace number instead generates a string for the workspace number.
Let me know if you want this and I'll rejig and resubmit the patch.
I suppose so. I've never heard of multiple workspaces on Windows other than by non-standard utilities so any links would be appreciated.
Any NT-system supports "virtual desktops". Win 9x does not.
google site:msdn.microsoft.com Window Station and Desktop Functions, http://technet.microsoft.com/en-us/sysinternals/cc817881.aspx
For example, the login screen is on separate desktop, with a higher level of propection that the regular ones; XP "fast user switching" creates per-user window stations, and desktops within them.
Almost no applications support these. For example, if you run FF on two desktops, the 2nd instance will say "FF is already running" and exit. Windows itself does not handle them very well: Task Manager and the Ctrl-Alt-Del window are always displayed on the initial desktop, but the system does not switch to it, and it looks like nothing happened.
OK, thanks. It seems it's not that important to support Windows workspaces.
Regards, Nick
Hi,
Attached is a version of this patch updated to apply cleanly against SVN HEAD.
Cheers, Erik
On Thu, 9 Sep 2010 20:12:18 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Attached is a version of this patch updated to apply cleanly against SVN HEAD.
Thanks, applied. This is a great improvement IMO :)
BTW, the patch code style did not fit with Geany - I fixed it. You might want to read:
http://geany.org/manual/dev/hacking.html#style
Regards, Nick
Nick Treleaven wrote:
On Thu, 9 Sep 2010 20:12:18 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Attached is a version of this patch updated to apply cleanly against SVN HEAD.
Thanks, applied. This is a great improvement IMO :)
Awesome. Thanks.
BTW, the patch code style did not fit with Geany - I fixed it. You might want to read:
Will keep that in mind.
Cheers Erik
On Wed, 15 Sep 2010 18:07:45 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 9 Sep 2010 20:12:18 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Attached is a version of this patch updated to apply cleanly against SVN HEAD.
Thanks, applied.
I discovered that Geany's instance logic will need fixing due to this change - if a socket is used, the current logic assumes it's the first instance and loads the session. I'll look at this next week unless anyone beats me to it.
Regards, Nick
Hi,
Le 15/09/2010 19:07, Nick Treleaven a écrit :
On Thu, 9 Sep 2010 20:12:18 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Attached is a version of this patch updated to apply cleanly against SVN HEAD.
Thanks, applied. This is a great improvement IMO :)
I run this patch now, and I don't link the behavior it brings. I personally use one single desktop for editing code source, but sometimes want to open files from another desktop in the "default" Geany instance.
So I would like to get the old behavior back. I see 2 solutions: 1) remove this patch; 2) add an option to choose whether we want one instance per workspace or not.
I think nobody wants solution 1, so let's forget about it and investigate a bit solution 2. Looking a bit at the code, I see three possible solutions:
1) in ui_get_current_workspace() (ui_utils.c, line 2476), return always the same value if the per-workspace option is not checked. Not sure whether 0 is a good value since it is the ID of the first desktop, but I'd think we don't care since it is a preference. The only way I see it may get confusing is if the option gets enabled while the first instance is not in workspace 0, and then a new Geany gets launched from desktop 0. In this case, no new instance is launched since it already exists, even if not launched from desktop 0. But this is the same if the Geany's window changes workspace after it has been launched (but this is a bug IMO).
2) in socket_init() (socket.c, around line 288), add the _wsX suffix to the socket file only if the per-workspace option is checked. This has similar flaw than solution 1: if the option gets activated and another instance get launched, it won't see the already running one (since the existing socket would be geany_socket_HOSTNAME_DISPLAY and not geany_socket_HOSTNAME_DISPLAY_wsWORKSPACE.
3) this is the most complicated but also the one that seems to have the less flaws: still add workspace suffix, but when checking if there is a running instance to which send the requests, ignore that workspace information if the pre-workspace option is not checked. It needs to list the available socket(s), and then select the one we want (probably the first or the one closets to the current desktop), but it fixes flaws I see in both methods 1) and 2).
This said, I would personally choose method 1: it is the simplest one ant it is probably enough. I thing it isn't really a problem if the behavior is a little odd when the preference was just toggled.
So, what do you think? I can write a patch for one of these solutions (especially 1 that is really easy :p), or another if somebody has a better idea :)
Regards, Colomban
PS: offtopic: don't the new instance ran with -i also have a socket file!? I can't see them neither in /tmp nor in ~/.config/geany...
Colomban Wendling wrote:
So I would like to get the old behavior back. I see 2 solutions:
- remove this patch;
- add an option to choose whether we want one instance per workspace or
not.
I think nobody wants solution 1, so let's forget about it and investigate a bit solution 2.
I'm fine with solution 2, would not be fine with solution 1 :-).
- this is the most complicated but also the one that seems to have the
less flaws: still add workspace suffix, but when checking if there is a running instance to which send the requests, ignore that workspace information if the pre-workspace option is not checked. It needs to list the available socket(s), and then select the one we want (probably the first or the one closets to the current desktop), but it fixes flaws I see in both methods 1) and 2).
I prefer this solution, mainly because it doesn't have the problems the other two solutions have.
Cheers, Erik
On Wed, 29 Sep 2010 09:52:19 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
- this is the most complicated but also the one that seems to have the
less flaws: still add workspace suffix, but when checking if there is a running instance to which send the requests, ignore that workspace information if the pre-workspace option is not checked. It needs to list the available socket(s), and then select the one we want (probably the first or the one closets to the current desktop), but it fixes flaws I see in both methods 1) and 2).
I prefer this solution, mainly because it doesn't have the problems the other two solutions have.
In any case, the patch introduced a bug where 2nd instances still load the session files. So I think we'll need to revert it until there's a fix.
Regards, Nick
On Wed, 29 Sep 2010 18:00:06 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 29 Sep 2010 09:52:19 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
- this is the most complicated but also the one that seems to have the
less flaws: still add workspace suffix, but when checking if there is a running instance to which send the requests, ignore that workspace information if the pre-workspace option is not checked. It needs to list the available socket(s), and then select the one we want (probably the first or the one closets to the current desktop), but it fixes flaws I see in both methods 1) and 2).
I prefer this solution, mainly because it doesn't have the problems the other two solutions have.
In any case, the patch introduced a bug where 2nd instances still load the session files. So I think we'll need to revert it until there's a fix.
So both require traversing the possible sockets. It can be something like this <attachment>. But I'd personally prefer the patch removed...
On Wed, 29 Sep 2010 18:00:06 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
- this is the most complicated but also the one that seems to have the
less flaws: still add workspace suffix, but when checking if there is a running instance to which send the requests, ignore that workspace information if the pre-workspace option is not checked. It needs to list the available socket(s), and then select the one we want (probably the first or the one closets to the current desktop), but it fixes flaws I see in both methods 1) and 2).
I prefer this solution, mainly because it doesn't have the problems the other two solutions have.
In any case, the patch introduced a bug where 2nd instances still load the session files. So I think we'll need to revert it until there's a fix.
I've now copied the code to branches/workspace-sockets and reverted the code in trunk. Hopefully we can fix the issues and merge back sometime.
One idea besides having a pref for this is to have a command-line option to use the 'main' socket instead of the current workspace.
Regards, Nick
Le 07/10/2010 16:17, Nick Treleaven a écrit :
On Wed, 29 Sep 2010 18:00:06 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
- this is the most complicated but also the one that seems to have the
less flaws: still add workspace suffix, but when checking if there is a running instance to which send the requests, ignore that workspace information if the pre-workspace option is not checked. It needs to list the available socket(s), and then select the one we want (probably the first or the one closets to the current desktop), but it fixes flaws I see in both methods 1) and 2).
I prefer this solution, mainly because it doesn't have the problems the other two solutions have.
In any case, the patch introduced a bug where 2nd instances still load the session files. So I think we'll need to revert it until there's a fix.
I've now copied the code to branches/workspace-sockets and reverted the code in trunk. Hopefully we can fix the issues and merge back sometime.
Cool (for me :D), I'd also think it needs a little more incubation. IMO the current design is a bit flawed since if the instance is moved to another workspace, it still behaves as if on its original workspace. Not sure how this could be fixed, but it needs to be fixed before merging to trunk IMO.
I don't know what's possible to do, but I see some possibilities:
1) Detect workspace change, and then change socket name. This is not really easy since it needs handling the case when there is already an instance on this workspace.
2) When trying to open a file on a running instance, ask its workspace before actually sending the commands. This needs to list existing sockets and add a way to communicate the workspace through it. But then, this would look like: socket = None for s in socket_list: if s.workspace == current_workspace: socket = s break if socket is not None: socket.send_command(...) else: open_new_instance() Note that the sockets no longer should be workspace-suffixed, since this workspace ID would sometime be wrong. Better use a random/incrementing suffix.
Perhaps a look at how GEdit handles this would provide some ideas?
One idea besides having a pref for this is to have a command-line option to use the 'main' socket instead of the current workspace.
Why not, but it's not really convenient for those who use launchers: they need to be modified. But it would fix the problem that the prefs are currently loaded *after* socket checks.
BTW, I join the first patch I did to implement my 3rd proposal so if anybody's interested, they can take a look. I run it since I wrote it (a week ago), and seems to work fine -- apart the pref that is not loaded at the time I use it.
Regards, Colomban
On Thu, 07 Oct 2010 19:04:04 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
- When trying to open a file on a running instance, ask its workspace
before actually sending the commands. This needs to list existing sockets and add a way to communicate the workspace through it. But then, this would look like: socket = None for s in socket_list: if s.workspace == current_workspace: socket = s break if socket is not None: socket.send_command(...) else: open_new_instance()
Now that's a good suggestion IMHO. :)
Supposing there will be a preference or command line option open_on_same_desktop:
workspace = INT_MAX socket = None for s in socket_list: if abs(s.workspace - current_workspace) < workspace - current_workspace: socket = s workspace = s.workspace if workspace == current_workspace: break
if socket is None || (open_on_same_desktop && workspace != current_workspace: load_default_session = socket is None open_new_instance() return
...continue with socket.c "now we send the command line args"
(Of course, this only takes place if no --socket-name is specified.)
On Wed, 4 Aug 2010 09:14:17 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
The following bug on sf.net:
http://sourceforge.net/tracker/?func=detail&aid=2896027&group_id=153444&atid=787794states:
If I work, I have often open more projects on more workspaces. And I have more runned Geany, too. But if I want open some file, it is open in window of Geany which was open first. I would like to open file in Geany which is at the same workspaces.
You mean like this? I wrote it shortly after --socket-file was implemented, and am using it ever since. Should work with any POSIX-compliant sh.
I prefer a script, because it can be easily altered to, say, check if the file to be open is somewhere under your main projects directory, and run geany with a socket name based on the supposed project name.
Dimitar Zhekov wrote:
You mean like this?
Yes, a little like that, but I think it should be the default behaviour.
I prefer a script, because it can be easily altered to, say, check if the file to be open is somewhere under your main projects directory, and run geany with a socket name based on the supposed project name.
My patch does not break your script. You can continue to use it if you prefer it.
Erik
On Fri, 6 Aug 2010 09:11:56 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Dimitar Zhekov wrote:
You mean like this?
Yes, a little like that, but I think it should be the default behaviour.
And so do I, but things like this usually meet some opposition when pushed into Geany...
My patch does not break your script. You can continue to use it if you prefer it.
I'll probably alter it to check a few well-known directories of mine, and then fallback to the new default behaviour.
A slight change to your patch:
... if (err == Success && result == Success) { if (type == XA_CARDINAL && format == 32 && nitems > 0) ret = current_desktop[0]; XFree (current_desktop); } gdk_display_close (display); ...
will avoid the two returns, and close the display on unsuccessful operation.
Under GDK_WINDOWING_WIN32, you can get the current desktop with the "Window Station and Desktop Functions". But it's a name, not a number.
Dimitar Zhekov wrote:
A slight change to your patch:
... if (err == Success && result == Success) { if (type == XA_CARDINAL && format == 32 && nitems > 0) ret = current_desktop[0]; XFree (current_desktop); } gdk_display_close (display); ...
will avoid the two returns, and close the display on unsuccessful operation.
Hood catch Dimitar. An updated version of my patch is attached.
Under GDK_WINDOWING_WIN32, you can get the current desktop with the "Window Station and Desktop Functions". But it's a name, not a number.
If anyone wants to work work on this with me let me know. I have an idea for making this work but I don't have any windows machines handy.
Erik
On Sun, 8 Aug 2010 17:12:52 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
An updated version of my patch is attached.
Problematic. The patch per se is fine, but...
I have two Geany-s open: one on ws0, and another on ws1. After restarting, they both connect to socket ws#, where # is the workspace that was active when I was logging out. Consequently, one of them becomes new instance.
Seems that my xfce session manager / window manager restarts the applications using the root window on ws#. That may be to speedup the session start or view ws# ASAP. Of course, all Geany-s are placed on their proper workspaces.
Your patch would have worked if it could get Geany main window's ws, but that's a catch 22: the socket is checked to see if a main window should be open.
My script has the same flaw, but I'm using it with a Geany patched for X11 session management, which remembers the --socket-file option. However, with your patch instead of the script, no such option is passed/remembered.
Needless to say, I checked the patch both with and without full X11 session management. It doesn't make any difference.
On Tue, 10 Aug 2010 12:43:24 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 8 Aug 2010 17:12:52 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
An updated version of my patch is attached.
Problematic. The patch per se is fine, but...
I have two Geany-s open: one on ws0, and another on ws1. After restarting, they both connect to socket ws#, where # is the workspace that was active when I was logging out. [...]
Seems that my xfce session manager / window manager restarts the applications using the root window on ws#. That may be to speedup the session start or view ws# ASAP. [...]
Follow-up. I had to remember a few things, which are best forgotten...
You see, in XSMP, there is no such thing as "run a program on a specific workspace". The program is just started, then it connects to the sm and is recognized as a previous session client, and then some attributes (including workspace) are applied to the next window it opens - usually the application's first window, but may be preceded by a login window, splash screen etc. before the sm connection.
So, while the desktop environment can run a program on the "proper" workspace, that's not a requirement, and the workspace should normally be handled as described above. You really can't get Geany's ws# on session restart without the main geany window...
Dimitar Zhekov wrote:
Problematic. The patch per se is fine, but...
I have two Geany-s open: one on ws0, and another on ws1. After restarting, they both connect to socket ws#, where # is the workspace that was active when I was logging out. Consequently, one of them becomes new instance.
When a geany instance exits, it deletes its
~/.config/geany/geany_socket_xxx_yyy_0_wsz
socket. The only way I could see that these sockets remain across logout/login was if you don't kill your geany instances before you log out.
Is that the case?
Is that something you regularly do?
Erik
On Wed, 11 Aug 2010 16:27:43 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Dimitar Zhekov wrote:
Problematic. The patch per se is fine, but...
I have two Geany-s open: one on ws0, and another on ws1. After restarting, they both connect to socket ws#, where # is the workspace that was active when I was logging out. [...]
When a geany instance exits, it deletes its
~/.config/geany/geany_socket_xxx_yyy_0_wszsocket. The only way I could see that these sockets remain [...]
It's not about that. On session restart, the workspace of the _root_ window may be 0 or # for all instances. That's legal and normal under XSMP, my 2nd mail from yesterday describes why.
Is that something you regularly do?
Yes, because I use a patched Geany with session management. But even without it, on restart all instances connect to the same socket. This patch may work properly only if combined with a sm which always stores --socket-file in the session (current sm-s don't do that).
Dimitar Zhekov wrote:
It's not about that. On session restart, the workspace of the _root_ window may be 0 or # for all instances. That's legal and normal under XSMP, my 2nd mail from yesterday describes why.
Is that something you regularly do?
Yes, because I use a patched Geany with session management. But even without it, on restart all instances connect to the same socket. This patch may work properly only if combined with a sm which always stores --socket-file in the session (current sm-s don't do that).
But shouldn't the SM save the workspace the geany instance was running on for each geany instance? And if the SM saves the old workspace number and restarts it on the same workspace number, won't geany just do the right thing and create the socket as needed?
Sorry, i'm trying not to sound too dumb here, but I had never heard of XSMP and know little about session management.
Erik
On Thu, 12 Aug 2010 13:45:45 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Dimitar Zhekov wrote:
It's not about that. On session restart, the workspace of the _root_ window may be 0 or # for all instances. That's legal and normal under XSMP, my 2nd mail from yesterday describes why.
But shouldn't the SM save the workspace the geany instance was running on for each geany instance?
On logout, it saves the workspace, position etc. of the first window open after the application connects to the SM [== Geany main window].
And if the SM saves the old workspace number and restarts it on the same workspace number, won't geany just do the right thing and create the socket as needed?
On startup, it applies the saved settings, including workspace, to the first window open after the application connects to SM - there is no "restart on the same workspace". The session/window managers may do that, but it's not so trivial, and the other window settings must be applied anyway. So at least the light SM-s apply everything together.
Sorry, i'm trying not to sound too dumb here, but I had never heard of XSMP and know little about session management.
XSMP is a PITA. Take my word for it, using the Geany main window workspace is OK (but unimplementable), while the root window workspace is not guaranteed to work.
Nick/Enrico/Frank, maybe it's time to include X11 session management in Geany? It's been about two months now, so I'm quite confident it works properly.