On Jun 20, 2005, at 4:07 PM, Darin Adler wrote:
2) We translate text set up in HTMLTextAreaElementImpl whenever it's set from there (or we force a updateFromElement and then invalidate the cache so that the next access will get it from KWQTextArea). This has the benefit of being pretty easy to do, with the negative of requiring the cursor position and selection accessors to be aware of \r\n sequences and treat them as a single char
I like (1) best long term. But I think it's fine to do (2) first. It's likely we'll be reimplementing <textarea> to use HTML editing rather than QTextEdit some time soon anyway, so we can take care of (1) at that point.
Ok, sounds good. In terms of actually doing #2, I would suggest that forcing an updateFromElement and then invalidating the cache is the best way to do it, so we don't have the translation happening in 2 different places. However, I'm not sure about actually implementing this, since I'm not really familiar with how it gets called in the first place. When I looked at it, setting text in HTMLTextAreaElementImpl calls setChanged(true), which basically just walks up the tree and tells each element that one of its children has changed, yes? And then how does that translate into an updateFromElement call later? Or, more importantly, would there be any problem with simply calling updateFromElement directly after the setChanged call, and then setting m_valueIsValid to false so the next access will get the translated value from KWQTextArea? -- Kevin Ballard kevin@sb.org http://www.tildesoft.com http://kevin.sb.org