Re: Some bugs in NSOutlineView

[Fred Kiefer]

Hi Ivan,




Am 03.03.2015 um 00:47 schrieb Ivan Vučica:
> I've started writing an email similar to this one over two years ago (!)
> when I was writing an OPML editor.
>   https://bitbucket.org/ivucica/opml
> 
> I've recently decided to check on what's its state under GNUstep. It's
> in a state similar to what I left it in: buggy.
> 
> So what breaks under GNUstep? Apparently, gnustep-gui's implementation
> of NSOutlineView. :-)
> 
> 1. If two rows have the same content, opening one by clicking on the
> triangle will open the other one as well.
> 
> * Different NSXMLElements that happen to have attributes with same
> string *value* also return the same *pointer*. Which by itself this
> would be fine, and is probably not a bug by itself. However, outline
> view seems to differentiate its rows by the object value!
> * The user sets the value of first row to "abcd" which results in
> -outlineView:setObjectValue:forTableColumn:byItem: being called.
> * -...setObjectValue:... calls [[element attributeForName:@"text"]
> setStringValue:object];, where object = 0x12345 (for example).
> * The user sets the value of second row to "abcd" which results in
> -outlineView:setObjectValue:forTableColumn:byItem: being called.
> * -...setObjectValue:... calls [[element attributeForName:@"text"]
> setStringValue:object];, where object = 0x23456 (for example).
> 
> * So I have -outlineView:objectValueForTableColumn:byItem: which returns
> [[element attributeForName:@"text"] stringValue];.
> * This results in 0xABCDEF being returned for both the first and the
> second row.
> * If I click on the triangle next to first row, the second row gets
> opened as well.
> 
> The mentioned method implementations are in OPMLOutline+ViewRelated.m.

I think there is something fundamentally going wrong here. I am just a
bit unsure at which level. Is it the code in NSOutlineView or the
NSXMLNode implementation?
You write that different NSXMLElements may return the same pointer. This
is definitely incorrect. Could you please explain how you managed to
demonstrate this behaviour?

What I can see from the code in NSXMLNode is that we could get two equal
XML elements with the same value even in the same document. This may
look like the same elements when stored by the NSOutlineView. Here we
should think about what constitutes equality for XML nodes. Currently we
are using tree equality here, but we could also require in addition that
they have the same XPath, that is the same path from the root of the
document to the node. Somebody should check this on Cocoa. (I know, this
"somebody" always results in being me, but why is this the case?)
On the other hand your question is valid, shouldn't NSOutlineView rely
on identity instead of equality? That would be fairly easy to achive,
just change the frist parameter of the two map table constructors (in 2
places!) into NSNonOwnedPointerOrNullMapKeyCallBacks instead of
NSObjectMapKeyCallBacks. As this is really simple to do, could you
please check this yourself?
That way we still wont allow the same object in the outline view twice,
but really don't understand why we would ever need that.



> 2. Upon first doubleclick on a row to begin editing it, the input field
> appears, but is not editable.
>
> * Click on + on toolbar to add a row (or press + on the keyboard).
> * Doubleclick on the newly added empty row.
> * Try typing and observe nothing is visible. Click elsewhere.
> * The text may or may not actually appear in the outline itself (!!!).
> Thus, please observe the inspector, where the text appeared in the
> 'text' attribute.
> * Doubleclick on the same row.
> * Try typing again. This now works.
> 
> 
> It's interesting that opening an existing OPML file (try example.opml
> that comes with the source code) displays the contents just fine.
> 
> Anyone interested in taking a look? The app worked just fine on OS X
> when I was last working on it (except, if I remember correctly, undos
> which were probably broken).

I tired to debug through this behaviour and could not find the problem.
To me it looked like the NSTextView gets set up properly for the editing
and even the key strokes arrive there. It just doesn't get displayed and
the result never gets passed on to the model. Finally I got the idea to
check where the string of the NSTextView gets reset and this happens
while the  NSOutlineView gets redrawn. So I started to compare that code
to the corresponding code in NSTableView (or rather in GSTheme, as
somebody moved that code over there). There I spotted a tiny difference
and after changing that everything seems to work.

Fred