Re: [Edbrowse-dev] debian1

[Adam Thompson <arthompson1990@gmail.com>]

On Sat, Jan 04, 2014 at 03:03:54PM -0500, Karl Dahlke wrote:
> > Nope, web browsers aren't as forgiving as you thought.
> 
> Well the result of that is - we have to fill in all the missing variables,
> all the objects thatmight be present in a full visual browser,
> even if those objects and methods don't really do anything.
> This of course is DOM, and would have to be done
> before or after the big rewrite,
> so the effort would not be in vein.
> The more we know about DOM the better.
Agreed, though *all* the objects is a bit of an interesting subject.
Are we talking all the mozilla objects, the webkit objects,
the internet explorer objects, the <insert_your_favourite_browser_here> objects?
Personally I'd just go for the dom standard (I think there's one somewhere),
but that's going to be a *lot* of work to get to do anything sensible.

> 
> Or ... maybe ... there is a full open source js + dom we can leverage,
> like Chrome, but it has to be completely disentangled from screens
> and visual presentations.

I've looked for one and I think someone did something based around a gtk-less
webkit, but I'm not sure how maintained (or maintainable) it is.

Also, you mentioned that you thought edbrowse didn't make it into the current
Debian release. I'm pleased to say that it is in there (and I install it as
part of my usual set of packages on Debian installs I do).
Basicly they've kept the old mozjs185 package around.
It looks like they finally (and quite rightly) want to stop doing this.

Anyway, as for a progress update:
If you look at my git fork [1] I've got buildable js*.cpp files.
However it currently just segfaults, probably because of the new gc api.
It looks like you now have to use c++ objects to store any JSObjects you create
(something called a RootedObject I think)
to tell the GC not to dispose of the underlying JSObject.
What this means in terms of edbrowse is (I think from some initial debugging,
including building smjs 24 to get the debugger to show me what's actually
happening), is that keeping the js objects (like jwin etc)
in void * variables means that they get garbage collected as soon as they're
created (well practically). If this is indeed the case,
which it looks increasingly like it is, the rewrite's just got that bit harder.

Cheers,
Adam.
[1] https://github.com/arthompson/edbrowse