Gregory Casamento wrote:
> Author: gcasa
> Date: Mon Feb 16 01:31:23 2009
> New Revision: 27874
>
> URL: http://svn.gna.org/viewcvs/gnustep?rev=27874&view=rev
> Log:
> * Source/NSCell.m: Change to implement 10.3 and later behavior for
> the method setStringValue: as documented in Apple
I will provide example code which will illustrate that the change is correct.
Please also look at the documentation on apple's site which explains what
happens when a non-NSString is passed.
Gregory Casamento -- Principal Consultant - OLC, Inc
# GNUstep Chief Maintainer
__
"If Apple really allows non-String parameters to setStringValue: this is
rather a bug then a feature. If you insist to add this to GNUstep, it is
fine for me, but at least we should not break working GNUstep code for this."
Since it is documented on their site I would not classify this as a bug.
I just checked the Apple documentation. It says:
For Mac OS X v10.3 and later: If you use a class that responds to the
selectorattributedStringValue for the object value of a cell, the cell
uses that method to fetch the string to draw rather than the
stringValue method.
This is not wha
"I make these changes and you can comment on them. OK?"
I will test them once you commit to make sure it's what is expected.
GC
Gregory Casamento -- Principal Consultant - OLC, Inc
# GNUstep Chief Maintainer
From: Gregory John Casamento
To: Gregory John Cas
I realize that part of the code is likely wrong in setObjectValue:. I need to
correct that (or Fred can) when I have access to the code (in a few hours). I
had thought that I put an else there to use description as a fallback if
stringValue or attributedStringValue were not available.
As I
My understanding of *-config scripts is that they are put into a standard
place in order for applications or development scripts to be able to locate
a given package.
It doesn't really make sense that gnustep-config should live inside of the
GNUstep directories since it's purpose is to help to loc
Fred Kiefer wrote:
> I make these changes and you can comment on them.
It turned out that the patch I made had a big problem. :-)
The new code in itself was correct, but there is a long standing bug in
NSButtonCell #11946 (With a reference to the even older #4635). And as
long as the setXXXTitle:
On Mon, Feb 16, 2009 at 11:43 PM, Fred Kiefer wrote:
> Fred Kiefer wrote:
>> I make these changes and you can comment on them.
>
> It turned out that the patch I made had a big problem. :-)
>
> The new code in itself was correct, but there is a long standing bug in
> NSButtonCell #11946 (With a re
