Re: Problem with isRichText message

[Fred Kiefer]

On 12.11.2011 12:32, David Chisnall wrote:
> On 11 Nov 2011, at 23:55, Fred Kiefer wrote:
>
> > On 10.11.2011 15:12, Slex wrote:
> > > Morning, after some tests, with some softwares, i found that
> > > NSTextView returns NO from isRichText, even when it contains rich
> > > text.
> > >
> > > A GNUstep problem?
> >
> > Most likely it is a GNUstep problem, whom else could we blame?
> >
> > When an NSTextView is created it should be set to isRichText, where
> > did yours get set to NO? And when we load text into the text view
> > by setting the text storage directly we again need to tell the text
> > view whether this is rich text or not. I think Ink is doing this
> > wrong, but then we should check on Cocoa, how this gets handled
> > there.
>
> Slex is refactoring / improving XMPPKit and StepChat (the Jabber
> framework / client that was my teach-yourself-Objective-C project,
> and so contains some horrible code).  The NSTextView is loaded from a
> (Cocoa) nib file.  It has allows rich text set in the nib, and it
> does actually contain rich text (when he deleted the if ([textView
> isRichText]) check, we got an attributed string containing a load of
> attributes.  So, I suspect that this may be two bugs working
> together:
>
> 1) Not setting the property from the nib

GNUstep should be able to decode this attribute if it is set in the NIB 
file. I just verified with InterfaceBuilder that we are using the 
correct value here.


> 2) Allowing rich text
> attributes to be inserted into a text view that does not have the
> isRichText flag set

At least with InterfaceBuilder it is possible to have an NSTextView with 
the attribute isRichText set to NO and still having an attributed string 
as its contents.

> If this flag is not set, then bringing up the font and colour panels
> should not permit him to insert rich text into the chat box.  If this
> flag is set, then -isRichText should return YES.

I think in GNUstep it should be possible to bring up these panels, but 
the changes here should affect the whole text not just the selected part 
of it. I think I have seen cases where this worked differently. In Ink I 
was able to reproduce such behaviour. When loading a TXT file we should 
end up with a text view that doesn't use rich text. All the formatting 
operations there don't seem to have any result. (Which by the way I 
think is wrong, they should affect the display of the whole text but not 
be stored with it) Still the typing attributes get changed and when you 
enter new text it will be with the changed attributes.

I am pretty sure this used to be different when I first implemented Ink, 
but don't know why this was changed.