Re: [Gnustep-cvs] r29010 - in /libs/gui/trunk: ChangeLog Headers/AppKit/NSCell.h Source/NSActionCell.m Source/NSCell.m

[Wolfgang Lux]

Fred Kiefer wrote:

> Wolfgang Lux schrieb:
> > > [...]
> >
> > Chapeau! I had to look twice before I noticed the flicker.
>
> Oh, it is quite noticable on my computer. Don't know if this means  
> it is
> too slow or to fast :-(

I guess too fast; I ran GSTest on my dated and slow PowerBook ;-)

> > > Could you please explain the motivation of this change and perhaps
> > > together we may come up with a better way to achieve the same goal.
> >
> > The problem I attempted to fix is that [cell setStringValue:...] did
> > not have an effect while the cell is edited. The argument of the
> > message is saved to the respective cell attributes, but the field
> > editor was not updated.
> >
> > Now for the screen flicker in NSFormCell. The problem is that for  
> > some
> > reason I do not understand, the NSForm repeatedly redraws the edited
> > form cell while it is active. While the cell is redrawn it calls the
> > cell's -attributedStringValue method to read the string to be  
> > drawn in
> > the cell. This method now calls -validateEditing on its control view,
> > which in turn writes back the string to the cell with - 
> > setStringValue:
> > (I've attached a backtrace at the bottom of this mail). This had no
> > observable effect up to now, but now causes the screen flicker as
> > -setStringValue: updates the field editor.
> >
> > Now I think that NSForm should not draw the contents of the edited  
> > cell
> > in the first place; this should be the business of the field editor.
> > Incidentally, I have seen a similar effect for an NSTextField as I  
> > had
> > commented out the following code in NSControl's -drawRect: method.
> >
> >   if ([self currentEditor] != nil)
> >     {
> >       [_cell setControlView: self];
> >       return;
> >     }
>
> This code helps to stop redisplay while the cell is edited. We have
> similar code in NSTableView to prevent the edited cell from being
> redisplayed.

Yes, but the problem of this code is that the cell's border is not  
redrawn
when necessary. E.g., in the NSForm test of GSTest just start editing  
the
text field at the top of the window and then resize the window. The  
field
editor is redrawn, but the border is not. In fact, this is the reason  
why
I had commented out the quoted code locally a while ago (and then  
forgotten
about it). As far as I understand the comment in NSControl, the idea of
this "fix" was to avoid drawing the cell's contents twice, once from the
cell and once from the editor. However, it would look much more  
natural to
me to address this problem in NSCell's -drawWithFrame:inView: method and
only draw the cell's border if the cell is edited. I've attached the
corresponding patches to NSCell and NSControl below. Am I missing  
something
obvious here (apart from the fact that we probably should not even  
draw the
background of the cell when it is edited and hence will need an  
additional
method)?

CellDrawing.patch
Description: Binary data

> The problem with NSForm is that we cannot solve the problem
> that easily. If we don't draw the edited cell in NSMatrix, the super
> class of NSForm, then we will also miss to redisplay the title of the
> cell (as well as any border, but this is also the case in the other  
> places).
>
> The other way to intervene here is to check whether the values we set
> actually changed and only pass on real changes to the editor. The
> problem with this is that I don't see a simple way to decide, whether
> the value changed.

Me neither.

> What I did, so to introduce another hack. We now only mark the cell as
> needing a redraw, when there is no editor for it. This looks OK on my
> computer, but could have other side effects we need to look out for.

I haven't tested your changes. But I didn't notice any flicker after
applying the patch above to r29013. Could you please test?

Wolfgang