User-visible Changes: * Automatically-resizing xwidgets If you change the size of the window containing a browser window, Ezbl will automatically resize the xwidget to fit the new size. * Cookie handler Ezbl is now able to honor cookie PUT and GET requests from Uzbl, using Uzbl's (relatively) new "talk_to_socket" system. This means that it is not having to spawn a Python process for each and every cookie on every page you visit, but is talking over a UNIX domain socket (which is fast). This, combined with the new event system has enabled the following: * No more handler.py script Ezbl is now 100% Emacs Lisp, and does not need to launch external processes (aside from Uzbl, of course :). This is largely achieved through the new event-manager system, which lets Uzbl notify Ezbl of changes and events over Standard Output, making for a very quick communication. * Much faster performance This is largely related to the event and cookie handlers, but it bears repeating. In a few tests of loading yahoo.com, Ezbl would take about 30 seconds to finish loading the page. That time has now shrunk to just over 2.5 seconds. By using the event manager to let Uzbl notify us of changes, rather than querying and polling, the amount of dead-time has decreased dramatically. One commit in particular (d99f336) is responsible for the majority of this speedup. * New Emacs dependency Uzbl uses a special kind of socket type (SOCK_SEQPACKET) for its cookie handlers, and Emacs doesn't support such sockets (before 23.2, which I helped to add), so you will need to build a custom version of Emacs, available here: http://github.com/haxney/emacs Note that you need the "xembed" branch of that repository.
Performance has increased by about 10-fold (from "dismal" to "pretty good"), and most of it is due to a single, one-line commit. It truly is the little things that make all the difference.
As an example, loading Yahoo.com took about 30 seconds in the bad old version and it now takes just over 2.5 seconds to do the same thing, while remaining much more responsive during the whole load.
Anyway, it is getting to the point where it is starting to be actually useful (though without keyboard support, it still isn't ready to replace Firefox), which is really cool! The biggest limitation at this point is that it requires patches to Emacs that are not currently in any released version (though my SOCK_SEQPACKET patch is scheduled for 23.2!), so it isn't something you can just download and play with right away. I'm working with the people involved to try to get the relevant pieces in line so that experiencing the latest and greatest browsing system for Emacs isn't quite so big of a burden.
Once again, comments are always welcome, and definitely let me know if you have given it a try!
Wow!, thats are a lot of improvements... I'm following this project and commit you to keep working as up to now.
ReplyDeleteGood work!
Do I understand correctly that you want to make emacs handle cookie requests? why not use uzbl-cookie-daemon? then you wouldn't need to add support for SOCK_SEQPACKET, or am i missing something?
ReplyDeletethat said, cool stuff! keep it up
(not that i ever use emacs though ;-)
@Dieter: Yeah, I am having Emacs handle cookie requests rather than using the cookie-daemon. It probably would have made sense to use that, but I didn't think of it at the time. Also, I wanted to make Ezbl implemented in pure Elisp as much as possible.
ReplyDeleteThough, I guess since cookie-daemon comes with Uzbl, I can rely on cookie-daemon being available. Probably would have been smarter.
The only advantage to doing it this way is that it gives Emacs more direct control over the management of cookies, which people might like. I think what I'll do is add a configuration option to let the user switch between cookie-daemon and Ezbl's native cookie handler. Might even break Ezbl cookie handling into its own file.
The SOCK_SEQPACKET change was actually pretty easy (since it is so similar to SOCK_STREAM), and it's being included in the next version of Emacs, so it's not that big of an inconvenience (Ezbl needs out-of-tree patches to Emacs to work anyway, so adding just a few more patches isn't that bad).
My ultimate goal is to make Emacs (with Ezbl) a competitive and viable browser, since I think that all of the cool Emacs features could make for a really powerful browser. One step at a time, though :)
Thanks for a great browser core! I couldn't have even started if Uzbl didn't exist!
This is an awesome project. I wish emacs-stable had the xembed support.
ReplyDeleteMaybe it's best if ezbl is only dependent on uzbl-core, which is, if I understood correctly, the current direction. It would be much more customizable that way.
@goks Well, Emacs 23.2 is coming up, you're welcome to get coding ;)
ReplyDeleteI am currently planning on making Ezbl depend only on uzbl-core, ideally without even needing any other external programs at all, though I have to balance this with complexity and duplication of code. I think I'll add support for using Uzbl's cookie-daemon, but I don't want to have to rely on it.
Hi there. The link to the necessary branch of emacs is broken. Would love to try ezble, but I can't without the xembed branch!
ReplyDelete@Tom I just updated the URLs to the repos. It now lives at github.com/haxney/ezbl.
ReplyDeleteThanks for the interest!