jmb at netsurf-browser.org
Thu Jan 15 00:11:40 GMT 2009
On Wed, 14 Jan 2009, Michael Drake wrote:
> In article <Pine.LNX.4.64.0901142139190.2171 at login.ecs.soton.ac.uk>,
> John-Mark Bell <jmb at 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 non-trivial?
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 -> library]
>>> 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 and
> 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
> test suite.
Yes. Building such a testsuite is decidedly non-trivial :)
I've put last year's organisation application form on the wiki:
More information about the netsurf-dev