Re: [Gnustep-cvs] Added editing methods.

[Fred Kiefer]

Alexander Malmberg wrote:
> Fred Kiefer wrote:
>
> > --- gnustep/gnustep/core/gui/Source/NSControl.m    2004/05/28 
> > 23:49:15    1.63
> > +++ gnustep/gnustep/core/gui/Source/NSControl.m    2004/09/24 
> > 16:35:41    1.64
>
> [snip]
>
> >  - (void) validateEditing
> >  {
> > -}           
> > +  NSText *t;
> > +
> > +  t = [self currentEditor];
> > +  if (t == nil)
> > +    {
> > +      return;
>
> [...]
>
> This is wrong. You're completely ignoring the formatter. While this 
> isn't the first bit of cell-related code that doesn't handle formatters 
> correctly, I don't think it's a good idea to add _more_ such stopgap 
> code unless there's a very good reason. Thus, why? As far as I can see, 
> the code isn't used in -gui. How did you test it?

Sorry to have upset you so much that you did write this mail in this 
very offensive tone.
First, the code is not ignoring the formatter, the formatter will be 
used by the cell inside of the setStringValue: and 
setAttributedStringValue: methods. Not that hard to check this.
You propably compared this methods with the ones in NSTextField or one 
of the other implementations, where the formatter is used by the control 
subclass itself. The difference here is that there you have a delegate, 
which could handle the case, where the formatter is not able to convert 
the string, an NSControl doesn't have a delegate, so we cannot do this 
here. Doing the conversion here would just duplicate the code already in 
NSCell,  making it harder to maintain.

This change was something I started to work on at least a year ago and 
an early stage was even mailed to this list before, but I left it 
unfinished, because it will require further changes to the GUI library 
to have any real effect. Currently these are just a few methods being 
overwritten by all subclasses that actually use it (But than, we still 
need to provide these for subclasses outside of GUI). The next step 
would be to change the methods in NSTextField, NSTableView and NSMatrix 
to be more in line with the new superclass implementation. But if you 
are opposing this step , and perhaps will be able to present an argument 
for this, I am willing to learn.

What I am wondering is, what in the actual change made you react in such 
a way? Is it me? Is it the code? Or is it that I am working on areas 
that are not your main concern at the moment? I just don't get it.
What about not yelling at each other right from the start? When I did 
not understand a change that Quentin made, I asked him in an open mail 
why he did that and he was able to explain it. I thought he may be 
wrong, because the code looked wrong to me, but he had a reason for that 
code. I still think it is the wrong solution, but now I understand the 
problem better.

Fred