Re: [Edbrowse-dev] Dynamic Menus

[Adam Thompson <arthompson1990@gmail.com>]

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

On Thu, Mar 13, 2014 at 10:43:45AM -0400, Karl Dahlke wrote:
> Yes, they work now!
> It's not intrusive; if they give you any trouble at all then just
> comment out the call to rebuildSelectors() in html.cpp.
Well done for getting this working.
> Bring up jsrt, select a state,
> and You get two different sets of colors to choose from below,
> depending on whether the state is A through M or N through Z.
> This is how a lot of real world sites work.

Yeah, all works as expected on my machine.

> Fun? Sure it was fun, always fun to program new and interesting features.

Agreed.

> Expedient? Without doubt. I'm Trying to support more websites.

Yep, and this got in before the release which is a good thing.

> Forward looking? Well maybe. Just a little.
> My tags continue to be the representation of the page, js independent,
> and then the render selector function is part of a post scan,
> to see which js objects have changed,
> and map those changes back to the html tags, and report same to user.
> Maybe it's a prototype for where we want to go.

Yeah perhaps.

> Oh by the way, scanning the tree of js objects with a 100% js function,
> and doc writing the output in some ascii string,
> and converting that back into tags,
> that nifty idea is dead on arrival.
> Writing a prototype is a great way to see what works and what doesn't.
> It doesn't work because I don't have a good way to embed pointers to the
> js objects in the ascii output stream.
> Oh maybe a way %p but not a good way,
> and I need each html tag to point (t->jv) to its corresponding js object.
> And there are other ways that it doesn't work so well, as Adam has noted.

I hadn't thought of the pointer thing,
as you say prototyping is always a good idea.

> My first post-scan function isn't really too bad.
> It plods along, but none of the code is hard to follow.
> See rebuildSelector and rebuildSelectors in jsloc.cpp.

When I've got a bit more time I'll do this.

> If you have a moment, look at these and we can think about how
> it might scale up to a more general post-scan of any changes on the page.
> Also the newSelect() function in jsrt.

Yes, sounds interesting. Unfortunately my spare time is somewhat limited at the
moment, so I doubt I'll be able to seriously look through the code for at least a week.

> Meantime it's a little code that helps a lot.
> It's kind of cool to pick the state and have new colors appear
> in the submenu below.
Agreed, and it seems to run quickly as well.

> One more observation, with jspool = 2, smallest it can be, I ran into a site
> wherein things stopped working properly,
> but they worked fine with a larger jsppool.
> So I think sometimes we run into memory errors that aren't reported to us,
> and so we don't shut down js as we should.
Yeah.

> Adam mentioned this in a recursive situation.
> So sm js continues to hold mysteries.
I think the recursive situation is slightly different since I ran with jspool=8
and jspool=128 and got the same limit,
so it looks like smjs has some other setting controlling internal stack size
(or maybe just a recursion limit somewhere).
It'd be cool if we could alter this as well.
Also, once it stopped recursing, I could re-run the function again without
doing anything to js.

Would it be useful if I put a "Recurse" button in jsrt?

Cheers,
Adam.

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