[Edbrowse-dev] rerender

[Edbrowse-dev] rerender

[Karl Dahlke]

So many things are changing, I mean it's a complete redesign,
and I'm trying to keep the ship sailing in the meantime.
If I step back and think about it globally my head spins,
so I keep head down, stay focused, and make one incremental change at a time.

As we move forward, more things don't work in the old system,
and I can't maintain it forever.
With the latest push, edbrowse runs on the new system by default.
If you really need javascript, and I have badly broken it,
export oldsystem=1
to bring back the old system; but I can't guarantee how long
it will keep working.

The new system has a new 2 letter command, rr, for rerender.
It's a little bit meaningless now, but will make sense when
(someday) we have asynchronous javascript running.
Perhaps stock prices on the page have changed, which a sighted person
would just look at the screen and see the change; we would type rr for rerender.
When you do this now it just says "no change".
This has no meaning in the old system, or when not in browse mode,
or when js is inactive.

The point here is that rerender is called internally
after each javascript action.
Perhaps you clicked on a button, or changed a field
that has onchange code associated with it, or whatever.
The objects change, the screen is rerendered, and compared
against the old.
Like if you change the state in jsrt to Utah, which changes the color menu.

This is really really preliminary.
The comparison is done by strcmp.
If the screen is unchanged, and it almost always is,
that's the high runner case, I don't do anything and don't print anything.
Just move on.
If a single byte of the screen changes, I delete the old contents,
put in the new, and tell you that something has changed.
That's it, for now.
You get to figure out what has changed.
Of course I'll put in some more smarts over the next few days,
some kind of diff algorithm to tell you
"line 12 has been updated", and perhaps just changing that line
so I can retain your dot location and any labels you might have set.
That's coming but for now it's clunky,
just to prove the concept.
Yes, we can rerender the tree of nodes again and again,
and reflect any changes that have been made through javascript.

Karl Dahlke

Re: [Edbrowse-dev] rerender

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 3269 bytes --]

On Mon, Sep 14, 2015 at 05:17:32PM -0400, Karl Dahlke wrote:
> So many things are changing, I mean it's a complete redesign,
> and I'm trying to keep the ship sailing in the meantime.
> If I step back and think about it globally my head spins,
> so I keep head down, stay focused, and make one incremental change at a time.
> 
> As we move forward, more things don't work in the old system,
> and I can't maintain it forever.
> With the latest push, edbrowse runs on the new system by default.
> If you really need javascript, and I have badly broken it,
> export oldsystem=1
> to bring back the old system; but I can't guarantee how long
> it will keep working.

Yeah, I think we probably need to introduce a deadline on that as otherwise
there'll always be a reason to keep the code in the codebase.

> The new system has a new 2 letter command, rr, for rerender.
> It's a little bit meaningless now, but will make sense when
> (someday) we have asynchronous javascript running.

Yeah, that's on my todo list. Do we think that should be before or after the
duktape investigations?
> Perhaps stock prices on the page have changed, which a sighted person
> would just look at the screen and see the change; we would type rr for rerender.
> When you do this now it just says "no change".
> This has no meaning in the old system, or when not in browse mode,
> or when js is inactive.

Sounds good.

> The point here is that rerender is called internally
> after each javascript action.
> Perhaps you clicked on a button, or changed a field
> that has onchange code associated with it, or whatever.
> The objects change, the screen is rerendered, and compared
> against the old.
> Like if you change the state in jsrt to Utah, which changes the color menu.
> 
> This is really really preliminary.
> The comparison is done by strcmp.
> If the screen is unchanged, and it almost always is,
> that's the high runner case, I don't do anything and don't print anything.
> Just move on.
> If a single byte of the screen changes, I delete the old contents,
> put in the new, and tell you that something has changed.
> That's it, for now.
> You get to figure out what has changed.
> Of course I'll put in some more smarts over the next few days,
> some kind of diff algorithm to tell you
> "line 12 has been updated", and perhaps just changing that line
> so I can retain your dot location and any labels you might have set.
> That's coming but for now it's clunky,
> just to prove the concept.

Can't we do something fancy with our line mappings to do this?
It won't be particularly performant but we should be able to isolate the change to a line?

> Yes, we can rerender the tree of nodes again and again,
> and reflect any changes that have been made through javascript.

Excellent. I guess, once all this is finished,
the next step is to get the js to DOM link a bit more automatic such that any
attributes set on a tag's js object are reflected in the edbrowse
representation. Last time I checked this didn't happen but I've not checked the new code.
The same applies for js objects which represent nodes being automagically
incerted into the DOM. Again not checked the new code for this.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] rerender

[Karl Dahlke]

> Do we think that should be before or after the duktape investigations?

Implementing a complete DOM, with asynchronous events etc, is a big big deal;
looking at duktape is much more tractible I would think.
It's also orthogonal; you can work on that and I can continue to work on my side.

> any attributes set on a tag's js object are reflected
> in the edbrowse representation.

I'm not sure of the direction here.
I think if js sets any old variable foo=bar,
that does not need to come back to our tree of nodes for any particular reason.
However, if html sets    <tag foo=bar>
that should become part of our edbrowse representation, and then should be set
as a member in the corresponding js object.
The first part is already done.
I gather the attributes as tidy provides them and put them in t->attributes.
So we have access to them all.
>From there you'd think it would be a piece of cake to just loop through them
and call set_property_string(), and they're all in js.
But there are a few subtlties as per the dom.
There are exceptions.
I've probably only run into a quarter of them.
<span class=j> translates into classname = "j".
<A href=url> doesn't create the string href = url, but rather instantiates a URL object
and fills in all its components below.
And so on.
We can't mindlessly push all the attributes through to js,
we have to know what the exceptions are.

And yes, we need to be more automatic about creating js nodes parallel to our nodes.
It's mostly hard coded right now, and that's not very good.
We can move this toward automatic, but again, as above, there will be special cases.
<input type=radio>
isn't an input node at all, but an array of input nodes
one for each radio button.
Just an example.
The more I look at DOM the more special cases and exceptions I find.
So it will be some work for sure.
But we're moving in the right direction.


Karl Dahlke