On Wed, 14 Jan 2009, Michael Drake wrote:
John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
> On Wed, 14 Jan 2009, Michael Drake wrote:
> [CSS parser]
> Even if it isn't, there's not enough work left to fill 10 weeks. The
> selection algorithm can easily be implemented in a few days of full-time
> resource, and that's the only major thing outstanding. The remaining
> parsing issues are trivial in comparison.
OK. Although, IIRC GSoC wanted organisations to have ideas with a broad
range of difficulties and if a student finishes whatever project they
undertook early, I'm sure we could come up with some other stuff that both
the student and mentor would be interested in. :)
Er. There's 5 months between now and the start of GSoC coding. Therefore,
I'd have to not touch libcss again for there to be any chance of it being
a GSoC project.
As for libcss, won't integrating with NetSurf be a bit
I doubt it -- it's mostly search and replace. Anyway, in the first
instance, I'd just graft libcss' output onto what NetSurf's layout engine
expects. Everything's going to have to be modified to support dynamic
document/style changes, anyway. There's also the new DOM to consider.
> [Dynamic pseudo classes]
>> 7. Depends on libcss.draw.
> Likely. It's mostly layout, however.
Yep, we'd need some way for the core to know which bits of layout would be
affected, run layout on those bits and then redraw. I think partial layout
could take a fair bit of thinking about.
My intention was for it to be entirely event based, even for the initial
layout. If I get some time, I'll write it down.
>> 10. The changes to make rendering take into account margins, paddings,
>> splittings and nestings when plotting background colours, images
>> and borders are done. There are still other issues like white-space
>> property and vertical-align.
Line heights are also fixed since then. The unicode line splitting thing
mentioned on the old ideas page is not relevant, I think. It's a RUfl
issue, I think, because that stuff works on the GTK port. James?
Yes, it's a RUfl thing -- it has no knowledge of how to do linebreaking
properly (just splits on the nearest whitespace).
> [Keyboard nav, other platforms, page reader, RO gui code ->
>> The rest (2, 3, 6 and 8) can all be run again, as those aspects haven't
>> been touched.
> The first three seem reasonable. I have serious reservations about
> a) finding someone suitably qualified and b) the utility of extracting a
> library from the RO UI code.
Well a) shouldn't be a concern for us. Perhaps you're right for b),
although I think it might be nice. Maybe we could have an idea about doing
RO GUI work like tabs.
Still doesn't deal with (a) :P
>> Also, we can think up new projects. I'll have a think
about that for a
>> few days.
> One that is obvious to me is libdom. It needs the following doing to it:
> 1) Fixing so it compiles
> 2) Sort out the mess that is dom_string
> 3) Use vtables rather than known function names + switching on node type
> 4) Test suite
> 5) Write a binding to hubbub
> 6) The rest of DOM 3/2/1/0 implementing (primarily, Events)
Cool. I guess it's a bit early for discussing details, but maybe 1) should
be done before GSoCage.
It's trivial -- the current (partial) hubbub binding is broken.
The idea that leaps out at me is a layout and box tree test system
test suite. It would be ideal if we already had a separated layout engine,
but I guess something could be done like making a minimal NetSurf front
end and working off that. IIRC, there's a framebuffer front end which
doesn't do any framebuffer stuff. The tester could work by dumping layout
stuff like box tree with sizes and position details and matching with a
Yes. Building such a testsuite is decidedly non-trivial :)
I've put last year's organisation application form on the wiki: