In article <[email protected]>,
Michael Drake <[email protected]> wrote:
> I'll post possible new ideas separately.
These occur to me:
+ LibSVGTiny
- Support for <defs> and <use>.
- Support for joined shapes.
Like the letter 'o', which is two circular paths joined.
This is possibly an issue with NetSurf's plotter interface
not supporting joined paths.
- Use LibCSS to handle SVG's CSS
- Graduated fills
Radial fills aren't implemented, and I think there were
some issues with the meshing used in linear fills for
certain shapes.
Maybe James can comment on how suitable this is?
+ NetSurf bitmap handling
John-Mark has put some thought into this. NetSurf's current
handling uses a lot of memory, and decodes images that may
end up never being displayed. See this thread for more:
http://www.mail-archive.com/[email protected]/msg01387.html
+ NetSurf frames
Frames handling in NetSurf has always be difficult for the
front ends to implement. The task of handling frames
can be taken entirely into the core. I will produce a more
detailed plan for this soon.
+ LibNSFB / Framebuffer front end / LibNSFBTK
There are various things that could be done to improve the
framebuffer front end.
- URL completion
- Tabs
- Drags
- Local history, treeviews (global history, hotlist etc)
These are all generated by the core and drawn through
the plotters. I think these could be integrated nicely
into the framebuffer front end.
e.g. after some browsing, open local history, which might
replace the whole screen with the local history, clicking
on a thumbnail would return to the browser window, loading
the particular page that was chosen.
- Caret in text inputs
- Downloads
- Context sensitive pop-up menu
The core only uses two mouse buttons, so the third could
open a framebuffer front end menu.
- Toolkit
Maybe some of the framebuffer toolkit stuff could be moved
out into a separate library. Or into LibNSFB.
Perhaps Vince can comment on this?
Anyone got any other ideas?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
