> //If that's correct, there's no need to store two strings, and it > would > //make the code a bit simpler. > I thought a long time about this, maybe it will help to talk it out... > 1.) Setting .text sets .htmlText > - if .html is false, .htmlText = .text > - if .html is true, .htmlText = htmlversionof(.text) <= > Means inserting tags
Agreed. There's no doubt that tags are inserted, as htmlText is different from the input text. Because it inserts tags that weren't set, it must be getting its information from the text (what Gnash calls TextRecords). > 2.) Setting .htmlText sets .text > > - if .html is false, .text = .htmlText > - if .html is true, .text = parsedversionof(.htmlText) <= > Means removing tags Also agreed. There's no proof that the Adobe player actually drops htmlText tags, but since its htmlText getter evidently uses the TextRecords for its information, there wouldn't be any point in storing them. > 3.) cursor position (this is the part that makes me think we need to > keep two records) > - we should only step through characters that are displayed on the > screen > - the .text property contains only the characters that are > displayed on the screen This would also apply for what I was suggesting (i.e. the text property should only contain the characters displayed on screen), so that seems uncontentious. > - right now, .text contains both the characters that will be > displayed on the screen, and html tags ...and backspaces. > - html tags should be parsed and saved in .htmlText, so that .text > remains clean for cursor movement > 4.) in conclusion, with only one record, we could theoretically > constantly parse to move the cursor and output .text and .htmlText > OR > we can do what (i think) you are saying, and output .text > and .htmlText when needed from the already parsed textRecords. > it's just that this requires not re-formatting the whole thing > when one thing is changed, because if we did we would lose the record. This is a good point. That's something I've wanted done for a long time, but it didn't occur to me that it would be an obstacle here. On the other hand, it's a very good argument for the correctness of my suggestion. Not disposing of the records would be considerably less wasteful and generally hugely better, but would need a lot more rewriting. It would improve the code for things like backspace, where it looks like we store the code for it and back up during formatting. That means storing all the text, including backspaces *and* the deleted characters, for ever. Working directly on the TextRecords means being able to shift glyphs and glyph information between TextRecords, insert glyphs in the middle, split TextRecords and change properties or line position etc. This is a fair bit of work, but probably less hard than redesigning the formatting stuff. So there is potential for a lot of improvement, but... > I spent some time trying to get this to work, and it went to hell. ... it is indeed very difficult to sort it out without messing things up. Incremental changes are best, but because of the state the code was in when you started, it's not easy to do. > Sorry if this outline is a little scatter-brained, let me know > your thoughts. Personally I think keeping two records would make the > code easier to read, but I agree that if we were aiming for > streamlined and efficient, it should probably go the other way. That probably depends more on how it's structured than which approach you choose. Dropping the tags also almost certainly affects how html is parsed, which isn't properly tested, and which Gnash doesn't do exactly right (i.e. when tags are closed, what happens with non-closed tags, etc). With just a single text string, all the work would be done when setting properties (or input), and otherwise Gnash would just display the TextRecords. I appreciate that it is a lot of work to change it, and that's a good enough reason not to do it. On the other hand, if you do manage it, it would be probably the most important progress since the last release (the TextField work is going that way anyway). If you decide not to, it would be extremely helpful if you can bear the apparently more correct solution (whatever it is) in mind so that implementing it properly in the future isn't made more difficult. bwy -- Use Gnash, the GNU Flash Player! http://www.gnu.org/software/gnash/ Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
