[Gnash-dev] Re: [Gnash-commit] /srv/bzr/gnash/trunk r11358: framework for htmlText/text separation

[Benjamin Wolsey]

> //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