Dear Netsurf community!
I'm applying to GSOC for keyboard navigation, but got no response yet,
and was told on IRC that I should post my ideas to the mailing list.
Here are they (a little revised from what is in the application):
My proposal's content from the user's perspective:
(this is mainly for the PC's keyboard, but can be extended for others too)
- One-key default shortcuts for the most basic operations - like in Opera, for
F8 - focus the address bar
Z/Backspace - navigate back in history
X/Shift+Backspace - navigate forward in history
maybe J,K,^F,^B,^D,^U - scrolling the content for Vi fanatics
- highlight current text field - this is beneficial for the user for detecting
where is his focus as Jeff Atwood points out
- TAB and SHIFT-TAB for jumping between text fields (for example at login
- keyboard navigation - when the Shift key is being pressed, a little number or
character or string of characters next to each link is displayed on the
screen, which when typed on keyboard focuses that link. Four links will be
special which next to the string also display a little custom colored arrow,
each with different color, with the meaning which will be the next focused
link when navigated with Shift+Arrows (this is called spatial navigation)
An alternative way for displaying those strings next to the links without
worrying ALT/CTRL/SHIFT portability problems is to do it the Konqueror way:
hit and release CTRL. Just try it in Konqueror. It is pretty neat,
pretty much what I have on mind, but in K. it is restricted only to one
Altogether this is something like the spatial navigation + keyboard links
The workarounds for the pages with lots of links or with long
scrollable content should also be discussed well.
The typing of links is very similar to MS Office's new GUI and to a Firefox
extension or to Konqueror for which I have no screenshot (unfortunately I
don't have much time to do it right now):
again, a Jeff Atwood article for a screen shot of Office
[http://www.codinghorror.com/blog/archives/000825.html], and a screen shot of
hit-a-hint can be found here:
- support for Access Keys - [http://en.wikipedia.org/wiki/Access_keys]
Konqueror seems to use this effectively in his navigation
(when you press Ctrl twice)
What do you think? Are these feasible ideas?
I apologise if this question doesn't quite belong here, but I'm so
baffled by this I have to ask someone.
I was going to have a look at the NetSurf code and see if I could fix a
problem I had noticed (I've logged it too).
Being simple, I thought I could just stick printf()s in to watch
variables but I can't get it to print integer values. What on Earth's
Let's say in gtk/gtk_options.c I insert the following at line 144:
I see nothing. Something like
works fine. I realise this is elementary stuff but it's doing my head
in. Is printf() overridden somewhere? Is there some other strange thing
I don't know about?
I'm building the GTK version on Fedora 7.
Thanks in advance for any help,
I downloaded and built the NetSurf on Fedora 8 after clearing out a few
problems with help of rjek and jmb. After which I read through the
layout.ccode and understood how it works.. the structures, functions
Now that I have gained familiarity with the Layout code and line breaking
algorithm, I am positive that I can successfully handle the issues with
borders, margins, padding, backgrounds, css support. I would like to know
what is expected out of this project.
So that I can look into those issues and disover ways to overcome the
And it would be great if I am provided with a list of url test cases to test
my code and see to it.. that the issues are solved.. I have started working
on it. I later plan to run the NetSurf on the RPCemu emulator with RISC OS 3
review the work done.
This is my project proposal. Please do give feedbacks, suggestions on it!!
Improved Inline Element handling for NetSurf
Most HTML elements permitted within the BODY are classified as either
block-level elements or inline elements. Inline elements form the key to
formatting the page contents. NetSurf which closely follows the CSS
specifications such as the box model and visual formatting model. Hence my
aim is to improve the inline element support, especially enhancing the
borders, background image, CSS white space support and generating test cases
to the problems that NetSurf currently faces, i.e.
testing how NetSurf behaves and also testing how other standards compliant
browsers behave. (E.g. Firefox, Opera & Safari/Konqueror). And most
of all documenting the layout code and the linebreaking code more
IRC nick: manjeet
The entire project proposal is available at:
My project proposal for SoC 2008 is Improving the Inline element handling in
NetSuf . This is a bit of a mouthful for a project name so I'll begin by
what this multi-syllable contraption is supposed to do:
1.Generating test cases for all the problems that NetSurf currently
exhibits. Which would involve looking at what the specification says,
testing how NetSurf
behaves and also testing how other standards compliant browsers behave. (E.g.
Firefox, Opera & Safari/Konqueror).
2.Updating the code to fix the issues, which I have been able to identify
through my research along with help from NetSurf mentors.
* Inlines with borders are broken and disjointed borders when there is
* Background colors for inlines do not fill the area where padding is
* Background image positioning in case of inlines.
*Providing the support for CSS white-spaces (wrapping)
*Unicode line breaking algorithm
3.Doing a postmortem of code, checking for any regressions brought about by
4.Documenting the layout and line breaking code more explicitly.
*II. Implementation details and milestones :*
This project obviously is rather ambitious and while it would be
outstanding. I've heard that software development projects can sometimes,
you know, run late or have proposed functionality cut and scaled back. I've
envisioned the implementation plan for this toolkit as a set of independent
stages. The core idea is that completion of each stage produces a project
output that is self-contained, provides significant functionality, and can
be used on its own. I'm a complete believer in iterative development and
early and continuous integration; however the spiral will have to occur
within each stage, at least to the point where the output of that stage has
the features frozen, design and specification nailed
down, and beta quality code released.
1. Understanding the HTML layout and display code. (layout.c and
html_redraw.c) [ Completed ].
2. Generating test cases for all the problems that NetSurf currently
exhibits. Which would involve looking at what the specification says,
testing how NetSurf
behaves and also testing how other standards compliant browsers
behave. (E.gFirefox, Opera & Safari/Konqueror).
3. Fixing the problem of Inlines with borders, which are broken and
disjointed borders when there is padding present. I have understood from
That layout.c and html_redraw.c will be files I will be dealing.
Layout.chas only two entry points layout_document() and
The CSS box model describes the rectangular boxes that are generated for
elements in the document tree and laid out according to the visual
model. Each box has a content area (e.g., text, an image, etc.) and optional
surrounding padding, border, and margin areas; the size of each area is
properties defined below
-The margin, border, and padding can be broken down into top, right, bottom,
and left segments
- Each box has four edges inner edge, padding edge, border edge and outer
Absolutely positioned boxes are constructed in the box tree in the same
place as if they were not absolutely positioned. Inline boxes are created as
INLINE_BLOCK. the background and borders of the element forming the stacking
context. The box tree is then be rendered using each node's coordinates. The
background style of the content, padding, and border areas of a box is
specified by the 'background' property of the generating element. Margin
backgrounds are always transparent. By handling the border details this
can be resolved.
4. Modify the code the width module in layout.c to enable background colors
for inlines where the padding is present by adjusting the width of box. The
box structure has the padding value for that box.
5. Developing the feature to support background image positioning in case of
inlines. Background image position is not correctly supported for inlines.
Sites such as Wikipedia place non-repeating images in the right padding
oflink text. NetSurf currently places the background image at the left hand
side of the inline, under the text. Various test case for this will be
generated and tackled one by one.
6. Providing support for CSS white-space (wrapping of text) .This property
declares how white-space inside the element is handled. Values can b normal
| pre | nowrap | pre-wrap | pre-line | inherit. The white-space processing
will be done as documented in the CSS specifications .(
http://www.w3.org/TR/CSS21/text.html#white-space-prop). This will be done by
understanding the behaviour html_text_decoration() and
html_text_decoration_inline() module in the html_redraw.c. With the logic of
the Unicode line breaking algorithm. As mentioned in the CSS standards.
This is my proposal for the Page reader GSoC idea.
I've done a little search to try getting something portable and
powerful, I found some interesting TTS engines like:
speech dispatcher (http://www.freebsoft.org/speechd): provides a
powerful device independant C Api to write TTS applications.
Gnome-speech library: This could be the best choice but the only problem
is that it may be not portable.
There's some other engines, and the choice need a study and some
feedbacks from the netsurf team
Well, maybe looking for portable engines isn't very efficient, the best
is to implement this system for each platform using one of the
platform itself engines but just keep the API.
The mentor of this project underlined some points:
* Overview mode, which announces the document headings
Reading headings that come from <hn> elements. This is a
good way to "introduce" the web page to the user
* Section skipping to allow swift to access to the next part of the
* Repetition of the current section or skipping back to previous
I believe the best way to do this is keyboard shortcuts.
Like using a magic key that enables the reader control and then hit some key
to perform a task (ctrl + N: for next document, ctrl +
R: start reading... things like that)
* How to differentiate link text from the rest of the text
* How to handle emphasis tags; <em> and <strong>
I spoke to jmb and takkaria, and they gave me some
interesting links to think about the subject
The user should also be able to customize the reader, like changing the
voice and so..., And he should be able
to tell the reader to read only some highlighted text part, that's very
Small (and mostly useless :) ) test. rjek was right, a Windows port based
on Cairo would bring in quite a lot of depdendencies. Not that much in
size, actually, but a lot compared to a GDI based port.
hello every body,
I would like to participate in GSoC 2008 under Netsurf. I went through the
project ideas list and found "new CSS parser and selector engine" project
idea very interesting. I am really interested in compiler process and
developed a lexical analyzer (written in C, source) and a
I would like to complete for this project. I have few questions , please
help me to clarify them.
1. I read that there are either options, that is to re-write the entire CSS
engine(according to the given API) or develop from the existing one. So I'd
like to rewrite the CSS engine according to the given API. (as a side note
please note that the hand coded lexer+parser combination work more fast,
than a generated one), but most of the part of the engine is written I also
feel it'd would be easy to continue to work from there. Please give me a
clue to pick one of the choices. (I'd love to re-write the engine still so
that I can apply the theories that I learned in theory of computing and
2. When writing the proposal should I give some implementation information
if I thought to re-write the entire engine again.?
I am computer science student in here. I particpated in GSoC 2007 as
well. I like C programming. My C programming project and others can be found
in my resume.
 - http://rajikacc.googlepages.com/scanner.tar.gz
 - http://rajikacc.googlepages.com/pretty_printer.tar.gz
 - http://www.cse.mrt.ac.lk
 - http://rajikacc.googlepages.com/resume_rajika.pdf
comp.lang.c - http://groups.google.com/group/comp.lang.c/topics
At long last, I've done some netsurf hacking. I attach a patch which
uses librosprite to provide sprite rendering in netsurf. I've hacked
the netsurf Makefile to build against my local copy of librosprite --
grep for -I../../ and -L../../ to find them. If someone could fix
these, or tell me how, that'd be great.
librosprite can be found at
svn://svn.netsurf-browser.org/trunk/netsurf. The test harness
requires SDL to run, otherwise, there are no dependencies.
I'd like to present for discussion the subject of my GSoC application,
"extracting the core into a library." Over the last several days,
I've discussed several possibilities and concepts with everyone in
#netsurf, and I feel like we all have some great ideas. Here are a
few of my questions and concerns:
1. How does everyone feel about the current directory structure of the
source? Should it be separated into a library and GUI section or
should we rely on the Makefile to compile the necessary components as
a library and leave the directory structure in tact? We should also
consider how we intend to package NetSurf once the library is
complete. Do we plan to distribute it as one entity or as two
separate packages? This answer may lead to a decision regarding the
2. How many libraries do we intend to have? One dev mentioned there
may be interest in having a library that fetches and parses content
and another that handles the layout and display of content.
Alternatively we could simply have one library that is kept separate
only from the platform-specific and/or GUI code. If we create more
than one library, what are your thoughts on how to separate the
3. The use of libtool has come up as one possible method of providing
a platform-agnostic library installation. This would add some
overhead as some scripts would be bundled with NetSurf to assist in
library installation; however it would be beneficial in that it
performs proper installation of static and shared libraries on several
platforms--it's worth noting that some systems do not support shared
libraries. This may be a matter of deciding which platforms we want
to support and whether libtool is beneficial and/or required to
provide that support.
4. It is also my understanding that the current API could use
revising, but there have been few specifications regarding which areas
are in need. I understand the whole system may need some tidying, but
knowing what areas are of particular concern would be beneficial. It
is good programmatic style to tackle the ugliest, most inefficient
code first because this creates the most benefits when cleaned up.
Any of your comments are welcome.
5. One of the goals of this project, as far as I know, is to provide
these features to any other application developers who would like to
use them. If this is the case, a decision should be made concerning
which features are a necessity in the library as opposed to features
that are simply recommended for inclusion. This could be a decision
affecting the API, the logical structure of the code-base, and is
somewhat-related to my concerns in #2.
These are the thoughts I have in getting started, all though I'm sure
more questions will arise as we move along. If anyone has any
concerns aside from these, please present them for open discussion
here on the mailing list.
Also, as a side-note, I'd like to point out that the comments I made
previously in #netsurf concerning the simplicity of moving the core to
a library was meant to imply that compiling the source as a library is
a trivial matter. The code I posted to the mailing list previously
demonstrates this fact as well as providing an example of the possible
changes the Makefile will incur once this distinction is made. This
project is really much more concerned with revising the API and
separating the code in a logical and manageable manner. Ideally the
concerns presented here will allow us to clearly define the project's
goals and--as a result--a timeline of events that must take place to
accomplish these goals. Your comments, concerns, questions, and
thoughts are all very welcome.