[Geany-devel] [PATCH] X session management support
enrico.troeger at xxxxx
Tue Dec 8 20:06:10 UTC 2009
On Tue, 24 Nov 2009 16:00:06 +0300, Eugene wrote:
sorry, I didn't manage to read and reply to your mail before. Even
though I'm really happy you invested so much efforts into this. Thanks!
(Everything of your original mail I snipped out is ok for me and I
spare us the 'yes, I agree' sentences :D)
> The implementation. I did not to extract it to separate source
> code files so far, but I'll definitely do it if you wish.
It might be better but can also be done easily later.
> XSMP requires a Geany instance to have the same XSMP client-ID
> when it is restarted by the session manager. I created new
> `--libsm-client-id' command-line option in order to specify it
> in restart command.
> Actually, I looked into claws-mail source code and did not find any
> code to maintain client-ID there. Maybe maintaining client-ID is
> not very important, so I can remove `--libsm-client-id' option if
> anyone votes against it.
On a side note, did you copy any code from Claws? This could be
problematic as Claws is released as GPLv3 while Geany is GPLv2.
> 1. Geany session management
> I have to use `--no-session' command-line option in restart
> command. Please see code comments inside [4.implementation.patch],
> the "FIXME" section. There I described, why I have to use the
> option and why it is bad.
> There is an easy fix: Geany instance should not save Geany session
> if the instance is run with `--new-instance' option. I consider
> this behaviour acceptable.
> 1. Building on Windows
> I had no opportunity to test building on Windows. Autotools and waf
> should simply fail to find libsm, thus XSMP support should be
Don't worry. I would just test it but unfortunately I destroyed again
my Windows test VM by accident...the second time already. Having image
files laying around on my hard disk seems to be a high risk here...
More seriously, I don't know how many users are actually compiling
Geany on Windows themselves but I doubt there are many at all. Once I
find the time to set up a test Windows box again, I'll give it try.
> 1. Handle all command-line options
> Most of command-line options, specified when running Geany, should
> go to restart command. Things get little complicated as some
> options need special handling (for example, I think that `--line'
> and `--column' options should not go to restart command).
> I think, the best solution of this code duplication problem is some
> kind of a "reverse" parser of GOptionEntry's. It does not make
> sense to write one when you have 10 options or so, most of which
> have string values. But if such a "reverse" parser existed, I would
> consider using it. Information about whether a particular option
> should/shouldn't go to restart command could be placed in a
> separate array near `entries'.
Maybe the other way round:
put our command line options with all their information into a
array of a struct which can be used by both, the GOptionParser (read:
the values of the array are read and put into a new GOptionEntry array
for the GOptionParser) and the SM code reads our custom array as well.
Not sure whether this works, I didn't really have a look at the code.
> * Should I write a plugin? If not, should I extract the code into
Since we need to have a SM specific option in Geany itself anyways, I
think it isn't worth moving the code into a plugin. Another problem
would probably be the restart handling within a plugin since plugins
might be loaded to late for this. Though not sure.
And Nick already put your code into a branch in SVN, I consider this
that we agree here :).
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Devel