On Tue, 24 Nov 2009 16:00:06 +0300, Eugene wrote: Hi,
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) > [4.implementation.patch] > > 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. Me too. > [4.implementation.patch]. > >Untested functionality: > > 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 > disabled. 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 :). Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc
pgpE7SHeJ5OHB.pgp
Description: PGP signature
_______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
