[Edbrowse-dev] debian1

[Edbrowse-dev] debian1

[Karl Dahlke]

but I'd rather not take edbrowse in this (firefox) direction if at all avoidable.

I quite agree.
It looks like the tail wagging the dog.

Karl Dahlke

Re: [Edbrowse-dev] debian1

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Also do you know if iceweasel has this feature?

I don't.  mozrepl is a Firefox extension, so maybe it would work.  My
friend uses Firefox's nightly snapshots, so his frontend may not work
with Iceweasel, if it lags significantly behind current Firefox.

-- Chris

Re: [Edbrowse-dev] debian1

[Adam Thompson]

On Sat, Jan 04, 2014 at 03:09:11PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > 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.
> 
> Yeah, I heard something about a headless webkit a while back, but I
> never tracked it down.
> Also, a friend of mine is working on a console browser that uses firefox
> as its backend.  It hooks into firefox via mozrepl.  Here's the brief
> description of mozrepl:
> 
> <quote>
> MozRepl lets you program Firefox and other Mozilla-based applications from the
> inside using a telnet client.
> </quote>
> 
> You still have to run firefox itself, but for those of us who don't care
> to spin up a GUI, you can run it under xvfb, which is a virtual X
> server.

I've played with xvfb in the past, never really got it to work particularly well though.
At any rate, it seems an aweful lot to get javascript and dom working,
and would make edbrowse basicly just a firefox client.
I've got no problem with using something like your friend's work,
but I'd rather not take edbrowse in this direction if at all avoidable.
Also do you know if iceweasel has this feature?

Cheers,
Adam.

Re: [Edbrowse-dev] debian1

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

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

Yeah, I heard something about a headless webkit a while back, but I
never tracked it down.
Also, a friend of mine is working on a console browser that uses firefox
as its backend.  It hooks into firefox via mozrepl.  Here's the brief
description of mozrepl:

<quote>
MozRepl lets you program Firefox and other Mozilla-based applications from the
inside using a telnet client.
</quote>

You still have to run firefox itself, but for those of us who don't care
to spin up a GUI, you can run it under xvfb, which is a virtual X
server.

His program is ncurses-based, closer to something like lynx,
but I'm thinking we could use the same trick for edbrowse.

His work is here: http://bmcginty.hopto.org/clifox.git

-- Chris

Re: [Edbrowse-dev] debian1

[Adam Thompson]

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