Re: NSTextField didn't change color on set...Color: while editing.

[Ivan Vučica]

Personally, I don't care much whether or not this specific behavior is changed. 
In fact, why not? 

I also don't find it problematic that existing (Cocoa) behavior is kept, since 
it is trivial to update the field editor in addition to the currently focused 
text field. 

The only counter argument for making the change is that free software written 
for GNUstep might see strange bugs under OS X which are, in fact, not bugs at 
all, but platform-specific quirks. Current behavior also allows greater 
flexibility, too: one can change the color to red in case of validation failure 
without displaying the color change live inside the field editor. Someone may 
actually want that behavior.

I feel Bluna may also misunderstand the reasons for Cocoa compatibility: it's 
not here just to facilitate porting of proprietary software from Cocoa (which 
is, let's face it, difficult since many APIs are missing). It is here so that 
free software written for GNUstep can easily flow in the other direction as 
well.

Creating super sets is definitely great thing to do and a strength of GNUstep. 
I don't think anyone could reasonably be against it. Modifying behavior of 
existing API may be a bad precedent; there are some other annoying APIs that 
could use modification of their behavior. But what far reaching consequences 
could that have?

Why not add -setBackgroundForFieldAndFieldEditor:(NSColor*)color or something 
like that? Or perhaps -setBackgroundUpdateAlsoUpdatesFieldEditor:(BOOL)buaufe?

19. 12. 2011., u 16:22, Riccardo Mottola <address@hidden> napisao:

> Hi,
>> On 19 Dec 2011, at 06:30, Bluna Ratimonkey wrote:
>> 
>>> http://savannah.gnu.org/bugs/?35101
>> I'm not sure I understand the rationale here.
>> 
>> - The behaviour is useful
>> - Developers expect it
>> - Apple doesn't do it
>> 
>> Apparently the third of these trumps the first two.  I disagree with that 
>> decision, and so does a lot of code in GNUstep.  It should be easy to port 
>> code from Cocoa to GNUstep, but I don't think there is any reason why we 
>> should not provide a superset of the functionality that Apple implements.  
>> Doing so seems to be entirely in keeping with the goal of GNUstep as I 
>> understand it: to provide a great Free Software development environment that 
>> (also) makes it easy to move Cocoa applications to other platforms.
>> 
>> If GNUstep is nicer to work with than Cocoa, then I think that's a feature, 
>> not a bug!
>> 
> yes, as long as we don't implement something which is incompatible with 
> Cocoa... I think it is worth to be a superset (= better). I didn't follow 
> closely the case here so I don't know if it applies.
> 
> Riccardo
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev