Re: Moving GNUstep applications to GPLv3
I support this change as well. We already have the choice for the user of the library in there: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. What I am not sure about is, whether we are able to change the license for old code, where the contributor is no longer in contact with us. Does anybody know about this case? Cheers, Fred Gregory John Casamento wrote: Great! What you explained is the intention. Later, GJC -- Gregory Casamento - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 8:23:27 PM Subject: RE: Moving GNUstep applications to GPLv3 If we decide to move to the new license, then my opinion on the best way for the project to proceed is to change the license of our applications (GWorkspace, Gorm, etc) within GNUstep itself to the GPLv3 license. All of the libraries should remain LGPL. You probably mean that the software which is currently under GPLv2 will be moved to GPLv3, and software that is currently under LGPLv2 will be moved to LGPLv3. I would personally support and welcome this change. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving GNUstep applications to GPLv3
On 27 Jun 2007, at 09:09, Fred Kiefer wrote: I support this change as well. We already have the choice for the user of the library in there: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. What I am not sure about is, whether we are able to change the license for old code, where the contributor is no longer in contact with us. Does anybody know about this case? To contribute to GNUstep people must assign copyright to the FSF ... so if we wish to change the license it's the FSF we have to ask. I have not looked at the LGLP3 at all ... so I don't know if it's a good change (though I tend to assume it is), but I've read enough of and about GPL3 to be quite happy with using it for tools/applications. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rework of NSView diesplay mechanism
Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rework of NSView diesplay mechanism
Fred, Thanks for looking into this. I will make some changes and do some tests later this afternoon to see if it corrects the issue. Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, June 27, 2007 4:30:25 AM Subject: Re: Rework of NSView diesplay mechanism Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rework of NSView diesplay mechanism
Fred, You were correct. I replaced the call with the one you suggested and it now works properly. I'm going to test it a bit more to see if there are any other issues. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, June 27, 2007 4:30:25 AM Subject: Re: Rework of NSView diesplay mechanism Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Moving GNUstep applications to GPLv3
Hi, On 2007-06-27 02:23:27 +0200 Nicola Pero [EMAIL PROTECTED] wrote: If we decide to move to the new license, then my opinion on the best way for the project to proceed is to change the license of our applications (GWorkspace, Gorm, etc) within GNUstep itself to the GPLv3 license. All of the libraries should remain LGPL. You probably mean that the software which is currently under GPLv2 will be moved to GPLv3, and software that is currently under LGPLv2 will be moved to LGPLv3. Well, since the code we have inside GNUstep has a copyright assignment to the FSF and it has the v2 or later clause, do we have a choice at all? or any restriction with older code? Currently I don't feel strongly against it and I think there are good reasons to move forwards (so to avoid potential problems with other projects, but that may be not of too great concern for us). Although rising a great flameware about licensing, a matter in which I am only a layman, is not my intention, I do remember I followed several discussions and remember some people felt the v3 inadequate or even counterporducing and it was better to stick with v2. Linus himself felt v2 was better until shortly when forks were menaced. I didn't have a look at LGPLv3 though, since the discussions I followed originated from Kaffe. Apart from obvious arguments like to keep up with times or to comply with advices by FSF it would be nice if people could write reasons against or in favor of this license update, especially if there are points where the arguments touch GNUstep specifically. Hot points for v3 regard especially the use of code in connection with the internet, sharing and online usage, applicaiotn server providers, etc. Our WebObject clones might be interested? Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving GNUstep applications to GPLv3
On Wed, 27 Jun 2007 10:09:37 +0200, Fred Kiefer [EMAIL PROTECTED] said: I support this change as well. We already have the choice for the user of the library in there: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License ^^^ Just to make sure this gets fixed: between versions 2 and 2.1 of the LGPL, the name was changed from the Library General Public License to the Lesser General Public License. Please make sure to change this when updating to version 3. Hubert as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. What I am not sure about is, whether we are able to change the license for old code, where the contributor is no longer in contact with us. Does anybody know about this case? Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
