From: Alan W. I. <ir...@be...> - 2001-10-31 04:36:50
|
To Alessandro and the plplot development team: With a relatively small amount of work, I got sip and pyqt installed, and after that getting the pyqt plplot gui to work without problems was extremely easy. (See notes at the end). Thanks very much for your help, Alessandro. The only change to existing plplot files is to plmodules.c where no existing function is changed and 3 additional functions to control the gui are patched in by the patch. All the rest is handled by the magic of dynamic loading. As you can see from the edited comments below, two python source files are required to run the gui. In addition, there are the current plmodule.c changes which ultimately, I think should be separated from plmodules.c. That separated source file could then be compiled into a separate shared object that was loaded independently from plmodule.so by the application (See license comments at the end.) The relevant files are attached to this message if you want to play with this gui. Note, example1 is a modification of xw03.py. Ultimately, this should not go into CVS. Instead, I will put my thinking cap on to figure out how to make the required changes for all the xw??.py examples so they can be run either as scripts (probably called from a main script) or from the GUI. I am sure there is lots more that can be done with the GUI, but even in its present preliminary state, there is a source code window and plotting window. So you can enter python commands (or read them from a file and subsequently edit them) in the source code window and run those commands to see what the immediate effect on the plot will be. Once you are satisfied you would currently have to use cut and paste to output the results to a file, but I am sure file output can easily be added as one of the GUI features. Anyhow, this preliminary GUI result seems quite promising to me, and I hope other members of the plplot development team will evaluate it as well. LICENSING: This must be discussed because we don't want any licensing uncertainties or incompatibilities. libqt is GPLed. The way KDE handles this is their libraries and applications that are independent of qt are LGPLed and everything else is GPLed. If we follow a similar approach, I believe there is a way to do it so that only the xw??.py example scripts (assuming I modify them to use the pyqt GUI) would have to be switched from LGPL to GPL. For example, libplplot remains completely independent of qt so it retains its current LGPL status. From a functional perspective the add-on gui functions should probably be separated from plmodules.c in any case, and that way plmodules.c can retain its LGPL license since it also won't depend on qt. Thus, I propose that we ultimately separate out the current plmodules.c add-ons in the patch to plmodules.c and assign a GPL license to that separated C code. (The qplplot.py and prova.py files must also be GPLed.) Will you confirm you are in agreement with this GPL licensing approach, Allesandro? (I am asking you this because I presume you are the principal copyright holder of these plmodules.c add-ons and the added python files, but if not, please make sure the question gets answered by the copyright holder, and please inform me of who the copyright holder is.) That of course means the xw??.py applications that will actually use the add-on GUI shared object and libqt must also be GPLed. Certainly, I am happy if xw??.py are licensed this way. However, when I created those files, I edited a copy of the x??.py examples, which I think were originally created by Geoffrey. Also Rafael made some contributions so I believe I need agreement with both Geoffrey and Rafael for this license change to the xw??.py examples. Aside from the xw??.py license question, we also need to discuss our willingness to accept GPLed code (so long as it is done in a way that is legally acceptable and which does not force us to change our other licenses) into the plplot project. I think with some care (as is employed, e.g., in the KDE project) our principal LGPL licensed material and these GPLed add-ons can live peaceably and legally together. I am willing to take that licensing care by doing the configuration and programming work so the current plmodules.c add-ons are separated into their own GPLed C code file which gets compiled to a separate shared object file. I am most impressed by the promising start for this pyqt GUI and hope to see it as part of PLplot. Let me know what you think of the GUI and also the licensing issues (if I have failed to cover any aspect of them). Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Tue, 30 Oct 2001, Alessandro Mirone wrote (shortend by AWI and edited for what he used.) > hello Alan, > I used --with-double, > and specified --with-python=/our/non/trivial/location. > Double libs are necessary for Numeric to work without any problem > of typecasting. > About qt: > -------------- > I use libqt 2.3.1, and my version of python is 2.0.1. > > You get PyQt-2.5.tar.gz and sip-2.5.tar.gz from > http://www.thekompany.com/projects/pykde/download.php3 > > you need the pyqt version that matches your qt, and you must have > the qt headers installed. > > Sip is mandatory. Sip has to be compiled first > ---------------------------------------------- > You get sip options by > ./configure --help > You have to specify the good path to qt directories. > > > The PyQt compilation follows the usual configure path > ----------------------------------------------------- > specifying the variables with_sip_includes, with_sip_libraries and > with_qt_dir > or passing them as options to configure should be enough > > > TESTING > --------------- > I compiled the patched version, put qplplot.py, prova.py and example1 > in the tmp/ melting pot directory where everything gets compiled. > Then you can test by > python prova.py > You can then popup the file menu, choose example1, and run it |
From: Alan W. I. <ir...@be...> - 2001-11-01 18:42:43
|
On Tue, 30 Oct 2001, Alan W. Irwin wrote: > Note, example1 is a modification of xw03.py. Ultimately, this > should not go into CVS. Instead, I will put my thinking cap on to figure out > how to make the required changes for all the xw??.py examples so they can be > run either as scripts (probably called from a main script) or from the GUI. To the plplot developers (and interested pyqt GUI developers): I have just figured out what changes have to be made to our xw16.py example to run it from the pyqt gui for plplot. I assume these changes will work for any of our xw??.py examples so that gives Allesandro a ton of examples to show off. (1) I have trimmed out everything until the line "def main():" The GUI only needs main() (or whatever you want to call it) defined and does not need all these preliminary imports. (2) Remove the plParseOpts, plinit and plend commands within main. The first is irrelevant, the second works, but bypasses the GUI, and the third makes it impossible to re-run the example from the GUI. With the above two changes, the modified xw16.py result looks good when displayed by the GUI with one exception. In the current primitive state of the GUI there is no page control so all the pages run through without stopping. I assume page control is something that Allesandro will want to address with high priority. BTW, all these pages are built and displayed so rapidly that you can just barely see them until the last one displays. This is a reflection of the building efficiency of Numeric and the display efficiency of pyqt and libqt. But don't take my word for it. See for yourself with any of our xw??.py examples (after you make the recommend changes to your local copies of xw??.py). ******************* I would now like to move on to a related issue: how to organize the python examples for the *non-GUI* case. What I am thinking of is making the above two changes for all the xw??.py examples, and renaming main in each case to the appropriate name of the example (x01, etc). Then I would create an overall examples script called pythondemos.py which does the preliminary required imports once (including all the examples), executes plParseOpts and plinit once, executes all examples as python modules, then executes plend. I also would do the necessary reconfiguration to make this new approach work smoothly. This python module approach would make our python examples much less cluttered for non-GUI testing. Also, it makes the examples much easier to work with for the current pyqt GUI case and potentially for a native Tkinter GUI case. Comments, please? Unless there are objections I plan to go ahead with this reorganization fairly soon. Alan |
From: Alessandro M. <mi...@es...> - 2001-11-01 22:08:44
|
Hello Alan, For me it's fine if you take my patches in plplot under LGPL. None of the changes to plmodule.c need libqt and Libqt is just needed by pyqt if you want to run the new qplplot widget. On the other hand qplplot.py is just a code that does not not contain libqt, so I think that you can license it in the form that you prefer (LGPL). I am happy that you like qplplot.py. My group (scientific software) and also our collegues working in the software group for data acquisition and processing at the Esrf ( european synchrotron) use a lot, and more and more, python. We have a also strong demand from the users for image analysys. This is the reason why I and my collegues are so interested in having plimage. If you agree I would like to submit to your kind evaluation, in the next weeks, small bunches of code ( as you suggested) in order to implement step by step a plimage that fits our needs and hopefully those of the plplot community. Best regards Alessandro Mirone |
From: Alan W. I. <ir...@be...> - 2001-11-01 23:37:55
|
Thanks Allesandro, for your willingness to at least LGPL your donated software. We have had a discussion fairly recently on this list about when the GPL would be required, and I was summarizing my recollection of what Rafael said. But I may have it wrong, and the situation here is more complicated then the situation we were discussing before. However, *something* is linked to QT in order to run the pyqt GUI since I must set LD_LIBRARY_PATH to point to where I have libqt located in order for your example to work. Thus, I think some minimal amount of stuff will have to be GPLed, but I am not sure of exactly what. I don't have an axe to grind about GPL versus LGPL, but I do want to get this right so it does not come back to haunt us later. What do you think, Rafael? (I suspect you don't have time to comment much so what is the fundamental principle I should follow here to decide what needs to be GPLed taking into account that some of the "linking" is simply a user choice to read in the source from some of the xw??.py demos.) Alan P.S. Allesandro, in response to your plimage question, I cannot commit to anything at this time. I would prefer to make sure the GUI base is fine (all license issues resolved and everybody happy with the configuration [which is a time-consuming issue, I am willing to work on]) and installed into CVS before even considering anything else. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Thu, 1 Nov 2001, Alessandro Mirone wrote: > Hello Alan, > > For me it's fine if you take my patches in plplot under LGPL. > None of the changes to plmodule.c need libqt and > Libqt is just needed by pyqt if you want to run the new qplplot > widget. On the other hand qplplot.py is just a code that > does not not contain libqt, so I think that you can license it > in the form that you prefer (LGPL). > |
From: Rafael L. <ra...@ic...> - 2001-11-02 00:19:07
|
* Alan W. Irwin <ir...@be...> [2001-11-01 15:37]: > We have had a discussion fairly recently on this list about when the GPL > would be required, and I was summarizing my recollection of what Rafael > said. But I may have it wrong, and the situation here is more complicated > then the situation we were discussing before. However, *something* is > linked to QT in order to run the pyqt GUI since I must set LD_LIBRARY_PATH > to point to where I have libqt located in order for your example to work. > Thus, I think some minimal amount of stuff will have to be GPLed, but I am > not sure of exactly what. I don't have an axe to grind about GPL versus > LGPL, but I do want to get this right so it does not come back to haunt > us later. > > What do you think, Rafael? (I suspect you don't have time to comment much > so what is the fundamental principle I should follow here to decide > what needs to be GPLed taking into account that some of the "linking" is > simply a user choice to read in the source from some of the xw??.py demos.) You are right, I am too busy right now, but since you mentioned my name in public, I feel myself in the obligation to reply :-) To the best of my knowledge, the QT library is released under a dual license, both GPL and QPL, at the users choice, I remember vaguely that the QPL and the LGPL are claimed to be compatible (cannot remember where, probably in the mailing list debian-legal). If it is true, this means that any LGPL product can be linked against QPL. I may be wrong, though. -- Rafael |
From: Alan W. I. <ir...@be...> - 2001-11-02 09:02:25
|
On Fri, 2 Nov 2001, Rafael Laboissiere wrote: > To the best of my knowledge, the QT library is released under a dual > license, both GPL and QPL, at the users choice, I remember vaguely that the > QPL and the LGPL are claimed to be compatible (cannot remember where, > probably in the mailing list debian-legal). If it is true, this means > that any LGPL product can be linked against QPL. I may be wrong, though. Thanks, Rafael for that reminder of the dual-license (GPL and QPL) for QT. It turns out that solves everything without us having to change any of our licensing for any of our programmes. After some further research I found the LGPL-QPL compatibility question asked on Debian legal http://lists.debian.org/debian-legal/2000/debian-legal-200004/msg00005.html. I found this via a google search so this is probably the most-linked reference on this subject. The two separate answers (that you can find in thread-next) are categorical that there is no incompatibility between QPL and LGPL so it looks like we are absolutely fine with regard to using this donated software under the LGPL. Maurice and Geoffrey were pretty smart when they picked the LGPL for PLplot! (The Debian-legal question also made some wishful prediction about pyqt license that raised some warning flags with me, but I just checked the most recent pyqt license, and I believe it is an MIT-X style license. Anyhow, the license is extremely short and understandable. You are completely free to do virtually anything with that software so our LGPL software links fine with it as well.) So I believe the original licensing concern I brought up has been completely answered. Alan |
From: <jca...@in...> - 2001-11-02 20:26:53
|
On Thursday 01 November 2001 23:37, Alan W. Irwin wrote: =2E.. | P.S. Allesandro, in response to your plimage question, I cannot | commit to anything at this time. I would prefer to make sure the | GUI base is fine (all license issues resolved and everybody happy | with the configuration [which is a time-consuming issue, I am | willing to work on]) and installed into CVS before even considering | anything else. | | Alan I must say that a plimage API is a recurrent demand from many Octave=20 and Plplot users, and I have made one attempt to naively implement=20 it. Now I don't have the time to evaluate Allesandro plimage, but it=20 is certainly welcome, and will not be forgot. Joao |
From: Alan W. I. <ir...@be...> - 2001-11-11 03:10:32
|
To Allesandro: Please let me know if/when you are subscribed to the plplot_devel list (see http://sourceforge.net/mail/?group_id=2915) so I don't end up putting double e-mails into your mail box. I have just put the relevant pyqt GUI front end files into cvs. There are a number of changes from your original files so could you please check that the cvs version works for you? I believe you were on the mailing list when I previously today gave instructions about how to access the latest cvs version, but I will send that separately if you didn't get that e-mail. Here is the quick cookbook for the pyqt GUI frontend for plplot (which I urge other plplot developers to try for themselves). (1) install libqt (devel version of binary package if you are not building it yourself). (2) install sip (Allesandro has given details before). (3) install pyqt (Allesandro has given details before). (4) clean checkout of plplot from cvs. Make sure there is no plplot dir in the current directory when you do this since the cvs checkout will create a new plplot directory in the current directory. (5) cd plplot; make configure; \ ./configure --prefix=/usr/local/plplot --with-double ; \ make (6) cd tmp; make pyqt_plmodule.so This makes the additional module that you need for the pyqt GUI. This module will be automatically made under configuration control in near future, i.e., the "make" command in (5) will soon make this module if pyqt is available. (7) Set your LD_LIBRARY_PATH environment variable to the directory where libqt resides on your system. On my system I compiled my own in a user account so I specify setenv LD_LIBRARY_PATH \ /home/software/kde2_download/debian_athlon_20011013/qt-copy/lib/ but you will want to do something different. I believe I could have avoided this if I had specified LD_RUN_PATH before building pyqt (or if that build had used -rpath). I recall I had to specify my qt location in any case for that build to work so specifying LD_RUN_PATH (see man ld) in addition would not be that difficult. (8) ./prova.py #Note this (and all other files you need) are in the CVS version so do not copy any other files into plplot tree for this test. This brings up the pyqt GUI front end for plplot. Click anywhere in the white box and simply type import xw08 (or any other of the xw?? examples except for xw09) and then click on file-->run to get many nice looking plot examples. Allesandro, once you have confirmed the cvs version works for you, could you please put some page control in the GUI so each page of xw08 (or any other of the multi-page examples) can be browsed? IMHO, this should be a high priority although I am sure there are plenty of other things you want to do with this GUI now that it is working and in the CVS version of plplot. Things I still need to do: automatically make pyqt_plmodule.so (or not) under configuration control depending on availability of pyqt. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: Alan W. I. <ir...@be...> - 2001-11-11 16:58:51
|
On Sat, 10 Nov 2001, Alan W. Irwin wrote: > (6) cd tmp; make pyqt_plmodule.so > > This makes the additional module that you need for the pyqt GUI. This module > will be automatically made under configuration control in near future, i.e., > the "make" command in (5) will soon make this module if pyqt is available. I have now commited changes to cvs so pyqt_plmodule.so is built automatically. (I also fixed a couple of bugs in the configuration that I had managed to introduce.) My overall impression is the pyqt GUI for plplot lacks features (such as page control) at the moment, but it is a good start, and also it has astounding speed compared to any of our other GUI's. So if you want to see this speed for yourself, build and install plplot with python support like you normally would. Then simply run the example prova.py from either the tmp directory or the installed examples directory (/usr/local/plplot/lib/plplot5.0.4/examples/python on my system). If you have pyqt installed, prova.py will work, otherwise it won't be able to find the qt module and will quit with an error message. If you get an error message having to do with libqt, then set LD_LIBRARY_PATH to point to the directory where the libqt library is located (this is due to a rough spot in the way pyqt is linked but I am preparing a wishlist bug report on that so hopefully it will go away with later versions). Once you have the GUI running, type in import xw01 (or whatever xw?? example you want to try). Feedback, please! (Especially on features that you would like this GUI to have.) Alan |
From: <jca...@in...> - 2001-11-22 10:51:35
|
On Thursday 01 November 2001 22:06, Alessandro Mirone wrote: | Hello Alan, =2E.. | If you agree I would like to submit to your kind evaluation, in | the next weeks, small bunches of code ( as you suggested) in order | to implement step by step a plimage that fits our needs and | hopefully those of the plplot community. I don't know if there has been some further particular conversations=20 with Alan about plimage. I have applied your original patch and,=20 after some modifications, got plimage to work (I created a x20c.c=20 demo). But I need some clarifications and further work from you,=20 before I commit the changes to cvs. 1-We need a description of usage, including the arguments=20 descriptions. See for example =20 http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4= =2E2/plshade1.html (but plain text is OK). 2-Your patch includes a plmoveimage() and associated functions and=20 PLESC driver functions. These are only used in qplplot.py. Are these=20 functions really necessary? For one thing, one is introducing a=20 function in plcore.c that is only meaningfull for plimage and a=20 particular driver, and for the other side there are lots of PLESCs=20 (if necessary, those could be colapsed just in one=20 PLESC_PLIMAGEOPS(arg)). Also, the "move" operation is not very usual=20 in plots. What is its purpose? 3-In plimage() you use a row vector as argument for the image, but=20 plplot generally uses a 2D matrix for similar calls. Is there any=20 reason for this? I am willing to commit my changes to cvs, without plmoveimage(), and=20 we could latter solve some other issues. What do you thing? Please=20 anwser to the list. Thanks, Joao | Best regards | | Alessandro Mirone | | | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2001-11-22 16:32:22
|
On Thu, 22 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote: > On Thursday 01 November 2001 22:06, Alessandro Mirone wrote: > | Hello Alan, > ... > | If you agree I would like to submit to your kind evaluation, in > | the next weeks, small bunches of code ( as you suggested) in order > | to implement step by step a plimage that fits our needs and > | hopefully those of the plplot community. > > I don't know if there has been some further particular conversations > with Alan about plimage. No because I don't have the qualifications to deal with it. So it is great that Jo=E3o has been able to make so much progress with plimage. > 1-We need a description of usage, including the arguments > descriptions. See for example > http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4= =2E2/plshade1.html > (but plain text is OK). Here, I can help. That html file was created from docbook source, see plplot/doc/docbook/src/api.xml. So if Allesandro creates a description of of plimage using any function from that file such as plshade1 as a template that would be great. If the description is submitted as ascii, I would als= o be willing to change it to the proper form for inclusion in api.xml. Alan email: ir...@be... phone: 250-727-2902=09FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: Alessandro M. <mi...@es...> - 2001-11-22 17:01:25
|
Hi Jo=E3o, it's great that you got plimage working!! I will certainly send a description of plimage. I agree that plmoveimage is not necessary and = we can discard it by the moment. Yes it is a good idea to collapse all those PLESC. I would like to keep the PLESC that disactivate the pixmap and metabuffer. That is because I am planning to = write things like xhairs ( or whatever shape ) from python. That lets you the freedom to ( just imagine) select a polygonal shape from an image for an integral or whatever having at the same time a visual representetion of the shape. The shape changes continuosly and might be very general so it's good to manage that from python. About the call to plimage we can discuss the arguments.. I have no particular preference so may be we could generate an analogous of pgimage. What do you plan todo? You commit a working plimage and the we refine the plesc? Or you want me to refine the plescs? As you prefer. By the moment I'll send a description of plimage = to generate the html Ciao Alessandro Jo=E3o Cardoso wrote: > = > On Thursday 01 November 2001 22:06, Alessandro Mirone wrote: > | Hello Alan, > ... > | If you agree I would like to submit to your kind evaluation, in > | the next weeks, small bunches of code ( as you suggested) in order > | to implement step by step a plimage that fits our needs and > | hopefully those of the plplot community. > = > I don't know if there has been some further particular conversations > with Alan about plimage. I have applied your original patch and, > after some modifications, got plimage to work (I created a x20c.c > demo). But I need some clarifications and further work from you, > before I commit the changes to cvs. > = > 1-We need a description of usage, including the arguments > descriptions. See for example > http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0= =2E4.2/plshade1.html > (but plain text is OK). > = > 2-Your patch includes a plmoveimage() and associated functions and > PLESC driver functions. These are only used in qplplot.py. Are these > functions really necessary? For one thing, one is introducing a > function in plcore.c that is only meaningfull for plimage and a > particular driver, and for the other side there are lots of PLESCs > (if necessary, those could be colapsed just in one > PLESC_PLIMAGEOPS(arg)). Also, the "move" operation is not very usual > in plots. What is its purpose? > = > 3-In plimage() you use a row vector as argument for the image, but > plplot generally uses a 2D matrix for similar calls. Is there any > reason for this? > = > I am willing to commit my changes to cvs, without plmoveimage(), and > we could latter solve some other issues. What do you thing? Please > anwser to the list. > = > Thanks, > Joao > = > | Best regards > | > | Alessandro Mirone > | > | > | _______________________________________________ > | Plplot-devel mailing list > | Plp...@li... > | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Joao C. <jca...@in...> - 2001-11-22 20:42:01
|
On Thursday 22 November 2001 17:16, Alessandro Mirone wrote: | Hi Jo=E3o, | it's great that you got plimage working!! | I will certainly send a description of plimage. | | I agree that plmoveimage is not necessary and | we can discard it by the moment. OK. | Yes it is a good idea to collapse all those PLESC. | | I would like to keep the PLESC that disactivate the pixmap | and metabuffer.=20 The PLESC_DOUBLEBUFFERING already does "write_to_window =3D 0/1" |That is because I am planning to | write things like xhairs ( or whatever shape ) | from python. xhairs already exists, as you might know, use plGetCursor() | That lets you the freedom to ( just imagine) | select a polygonal shape from an image for an integral | or whatever having at the same time a visual representetion | of the shape. The shape changes continuosly and might be | very general so it's good to manage that from python. You could as well just use plGetCursor() to retrieve the shape, then plot= it=20 in xor mode, try "./x01c -dev xwin -xor". | About the call to plimage we can discuss the arguments.. | I have no particular preference so may be we could generate an | analogous of | pgimage. I used pgplot years ago, so I don't remember how pgimage() works. Why not use the standard plplot way, "PLFLT **z"? It is a bit more diffi= cult=20 to dinamicaly allocate memory, but one could write a utility function for= it=20 (as well as an utility to return the maximum and minimum of such arrays,=20 which I believe is a very frequent operation on plplot and particularly i= n=20 plimage related functions. | What do you plan todo? You commit a working plimage | and the we refine the plesc? Or you want me to refine the plescs? I will commit my changes (in a couple of days from now), and we will latt= er=20 refine some details. OK? | As you prefer. By the moment I'll send a description of plimage | to generate the html Nice. No job is finish till the paper work is done :) (aarrrghhhh--agains= t me=20 I speek!) | Ciao | Alessandro Bye, Joao |
From: Rafael L. <ra...@ic...> - 2001-11-02 00:01:44
|
* Alan W. Irwin <ir...@be...> [2001-10-30 20:36]: > [...] Certainly, I am happy if xw??.py are licensed this way. However, when > I created those files, I edited a copy of the x??.py examples, which I > think were originally created by Geoffrey. Also Rafael made some > contributions so I believe I need agreement with both Geoffrey and Rafael > for this license change to the xw??.py examples. IIRC, I contributed five lines or so. That was the only piece of Python code I ever wrote in my life. I decline any intelectual property on that. Do whatever you want with my "code". -- Rafael |