|
From: | Fred Kiefer |
Subject: | Re: Problem with isRichText message |
Date: | Sun, 13 Nov 2011 14:38:24 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |