|
Another Pointless Blog - All the cool kids are doing it
[Recent Entries][Archive][Friends][User Info]
05:31 pm
[Link] |
All the cool kids are doing it WebCore. In Yelp.

Pluses: * Blazing fast. Startup goes from 2.8s to 1.9s. Startup limitation is now in yelp code (which I can work on) * API rocks. It's like a real gtk+ API. I can understand what's going on in it.
Minuses: * People will expect the choice now. * Frags apparently don't count as links, which means we'll have to deal with all events. Which sucks. * WebCore apparently doesn't play nicely with libxslt. More on this in a minute. * Scrollbars have gone AWOL.
Currently, the patch resides in bugzilla. It's ugly and disables lots of features. Once it's cleaned up a bit and more works, I'll consider (maybe!) landing it in SVN.
The problem with WebCore and libxslt. Any help most gratefully appreciated. The issue appears when trying to parse the next document after WebCore is initialised. The sequence goes something like: Yelp starts Initialise TOC Initialise and pages requested Create window as well as html (When user requests doc): Initialise new page.
When I do all this, it works beautifully up until the final step. Then, things go a bit squiffy: "/usr/share/gnome/help/platform-overview/C/platform-overview.xml:1: parser error : Document is empty
^ /usr/share/gnome/help/platform-overview/C/platform-overview.xml:1: parser error : Start tag expected, '<' not found
^ " Except the XML file definitely exists and is valid (I can display it normally). Things get even more fun for man and info pages, where the first step is to load the stylesheet using "transform->stylesheet = xsltParseStylesheetFile (BAD_CAST stylesheet);" This fails miserably and the entire program grinds to a horrible halt. So, anyone with experience of WebCore and / or libxslt want to comment and / or explain WTF is going on? There's a drink in it if you can solve it.
|
|
| |
| From: | (Anonymous) |
| Date: | February 3rd, 2008 05:52 pm (UTC) |
|---|
| | About scrollbars | (Link) |
|
I'm no WebKit or GTK+ guru, but maybe you should place the component in some kind of scrolling pane?
| From: | donscorgie |
| Date: | February 3rd, 2008 05:55 pm (UTC) |
|---|
| | Re: About scrollbars | (Link) |
|
Thanks. I've discussed with Xan Lopez on IRC about the scrollbars. He did (at least some of) the work in porting epiphany to use WebKit and pointed me in the right direction.
| From: | (Anonymous) |
| Date: | February 3rd, 2008 08:21 pm (UTC) |
|---|
| | No | (Link) |
|
No, REAL users (as in end users) will not care rats ass about having a choice. They just want it to work. It's supposed to view very simple stuff with relatively few formating tricks - even DILLO would suffice. If it takes as much as over one second to maintain mozilla version then dump it because the input/output ratio for maintaining alternatives is too much.
| From: | (Anonymous) |
| Date: | February 3rd, 2008 09:50 pm (UTC) |
|---|
| | Re: No | (Link) |
|
On the other hand displaying "very simple stuff with relatively few formating tricks" more than one second even on slower machine sucks. Therefore porting Yelp to more resource-savvy engine makes sense.
| From: | (Anonymous) |
| Date: | February 3rd, 2008 09:27 pm (UTC) |
|---|
| | Minus | (Link) |
|
It is not accessible.
| From: | (Anonymous) |
| Date: | February 3rd, 2008 10:38 pm (UTC) |
|---|
| | Re: Minus | (Link) |
|
Which is one reason we aren't going to just rip out Gecko tomorrow. Accessibility is something that can be worked on. And if the community is moving towards Webkit/Gtk, then you can be sure it will be worked on.
Of course, one could argue that chasing accessibility on Webkit when we already have it with Gecko is pointless. But Gecko has been a huge source of headaches over the last few years, and doesn't exactly have a spotless accessibility track record itself.
-- Shaun |
|