On Tue, 2009-01-27 at 20:01 +0000, Michael Drake wrote: > So the possible ideas so far are: > > > 1. Native Windows or Mac OS X ports > 2. Keyboard navigation > 3. Page reader > 4. Extracting the core into a library
This either needs specifying properly or dropping from the list. The issue we had with this last time is that it's far too open-ended. > 5. Layout engine improvements As above. What improvements? > 6. LibDOM This one, like Hubbub was last year, is well constrained (although, unlike Hubbub, it has the potential to get out of control). Best, I think, is to limit it to Core, Events, and possibly HTML. > 7. LibSVGTiny James: have you any thoughts about this? I have little idea of what the current state is, what needs doing, and how much work it might be. > 8. Automated NetSurf layout test suite Again, needs specifying properly. > 9. Improved GTK front end > 10. Improved Haiku/BeOS front end > 11. Improved RISC OS front end What improvements (for all 3)? > It would be good to have some more core related ones, I think. How about > that idea that's popped up a few times about allowing NetSsurf to make a > report of all errors and problems found with the HTML and CSS of a page > and the rewrite of NetSurf's internal logging handling? Rewriting logging is desirable. That said, I don't envisage it being a full summer's work for a half-competent student. Note that logging parse errors from the current CSS code is probably somewhat of a waste of time, given it'll likely be replaced some point during the GSoC cycle. > Also how about an idea related to general browsing efficiency, for example > only decoding images when they need to be displayed, making a disc cache, > and other stuff? Don't know how much work there is in that kind of thing. Again, this needs specifying properly. Additionally, this lot needs turning into an ideas page asap. We should also work on the application form. I transcribed last year's answers to the wiki and suggest we just work on it there. J.
