I have been looking at stopping the Amiga front end from #including
desktop/browser_private.h, like I did for the Windows front end earlier
The big problem with the Amiga code at the moment is that the tabs
implementation seems to depend on being able to dereference struct
browser_window (bw), to get to the struct gui_window (gw).
So, for example, to set the Amiga front end's scroll offset for the
window, it starts with a struct gui_window_2 (gw2), which I assume is the
main window containing all the tabs, then it goes to the bw (representing
current tab?), then the gw:
The gui management of tabs should not depend on core data structures.
I suggest that the gw2 be changed to have a pointer to a gw representing
the current tab, and add a pointer to bw entry in the gw. So to get the
scroll_y it would be:
And to use the core browser_window_* functions, you'd be passing the bw
Does that seem doable Chris?
Michael Drake (tlsa) http://www.netsurf-browser.org/
It seems like netsurf is a great candidate for providing HTML based UI in apps. Is this something anyone has tried from a technical point of view?
Does the current licensing support this for paid for apps or is netsurf licensable for such purposes?
OK, second attempt at international domain name support.
I've had to import some unrestricted code from elsewhere, due to the
necessity of Unicode normalisation and other things. It is working
and conforming to the spec, as far as I read it.
A couple of minor issues/todos:
1. If an invalid URL is encountered during page layout/box conversion,
NetSurf gives a BoxConvert warning and the page is never displayed.
This is caused by my new code making nsurl_create return
NSERROR_BAD_URL when an IDN fails the compliance checks.
I've not been able to work out where in the core this error code is
terminating page layout.
Page showing this problem:
2. If a frontend wants to display the UTF-8 version of an IDN then
currently the URL needs stripping into component parts, the host run
through idna_decode() and the whole thing put back together again.
This should probably be handled by nsurl but I'm not sure of the best
way to implement it.
3. There are some to-dos noted in code comments for further compliance
checking. They are optional in the spec, and I don't see any need to
implement them - anything invalid will be rejected by DNS. Most of
the mandatory checks seem overkill anyway, given that there is
stricter checking at DNS registration time.
I have included the optional decode-reencode check for already encoded
addresses to weed out any undecodeable nonsense the user might have
typed in, but it doesn't bother to do normalisation or validity
checking of the decoded address before re-encoding it (maybe it
should, I'm not sure, the spec was vague on this point).
In response  to
I had another look at it and couldn't see anything wrong with the
nsfont_split function. I cleaned it up slightly in , which should not
have changed the behaviour at all.
I think it's possible that the problem is in ami_font_width_glyph.
One way for the symptoms you get is for ami_font_width_glyph to be
returning different widths for the same character when it is at the end of
a paragraph, and when it is followed by a space.
So some difference due to kerning when the next character (char2 in
ami_font_width_glyph) is ' ' vs '\0'.
Because I constified the data pointed to by the utf16 and utf16next
pointers in  I had to fix up ami_font_width_glyph in  to fix the
build. There's a chance that commit  may have solved the problem, or
there's a chance I've broken it further if ESetInfo can't handle char2
Anyway, I think it's worth investigating the ami_font_width_glyph
function's behaviour with ' ' and '\0' for char2.
 I tried to register an account there a few hours ago, but perhaps that
Michael Drake (tlsa) http://www.netsurf-browser.org/
I have completely reworked the web search functionality in the core of
the browser. The new API is much simpler and robust. Currently only
two frontends (GTK and Amiga) use the functionality but I hope now
that it is so much simpler to use other maintainers might implement it
for their frontends.
I have fixed up both GTK and Amiga usage (apologies to chrisy if I
made an error in amiga) and the GTK frontend "search from the url bar"
functionality now actually works (set in preferences)
I have recently reworked the browsers url to path conversions to come
from teh file operations table and to use nsurl instead of strings for
urls. From this I have eliminated a great deal of duplicated,
problematic, conversion code.
There are two generic helpers available by including utils/file.h
nserror netsurf_nsurl_to_path(struct nsurl *url, char **path_out);
nserror netsurf_path_to_nsurl(const char *path, struct nsurl **url);
I have converted all uses of conversion to these functions but please,
please can frontend maintainers check my work. As ChrisY demonstarted
recently, even if the core change is correct and tested on one
platform it can mess up elsewhere.
This rework now means that almost all the netsurf internal API now
uses our nsurl url functions (missing is launch_url() set_url() and
save_url() which I intend to fix soon)
For many file related url handling this has greatly reduced the number
of string to url to string conversions and made our scheme handling
much more robust.
It is my hope that frontend maintainers are happy with this move, if
not can they explain their objections clearly and propose an
I also intend to extend the nsurl component API slightly to allow
retrieval of escaped path elements, my eventual thought here is to be
able to remove the old string based URL API (see utils/url.h)
HiI'm Raza ul Haq and I'm studet of computer science at The Islamia University Bahawalpur, Pakistan. I was thinking to make web browser foe my final year project. But then my professor told me that actually web browser is not actually an application which can be developed by one person in a short time, so you just find an open source browser and develop it's any portion for project. I searched about open source browsers I got netsurf, I've joined it's community and now I want to work with you people. So please tell me how can I contribute for you(related to programming), please be detailed as you can I'll be helpfull for me.ThanksRegards Raza ul Haq
I've just put a small patch in branch chris/http2 to enable libcurl to
use HTTP 2.0 if it is the latest version.
libcurl also needs building against nghttp2 for this to do anything
(there is an equivalent patch in the toolchains chris/http2 branch)
As it is still in draft I've put an option in to enable it, rather
than it being enabled by default. Certainly Google's server - if not
connecting over https - returns an error. Over https it works fine
(and appears to have negotiated http2 to some extent), so I think it's
probably just not up-to-date with the latest spec.
I'll temporarily add myself to the curl mailing list and ask about
Anyway, it's there for testing, merging, criticising, whatever.
As you will all no doubt have noticed I have been splitting the
browsers core functionality out from the front ends. The evantual aim
of this work is to be in a position to have a browser library around
which frontends can implement a browser suitable for their platform.
The functionality falls broadly into these catagories:
1) "library" type functionality which each frontend can use to perform
actions (like nsurl for handling urls and message code for handling
internationalised strings) which is mainly provided in the utils
2) Core browser functionality which provides everything from the
fetchers to the renderer.
3) Operations the core code requires the frontend provide. These are
accessed through an operations table which is currently initialised as
part of gui_init()
4) Frontend code.
My work so far has mainly been in the third area, but I am considering
all but the frontend code in this discussion.
I would like to start moving functionality out of the netsurf project
and into a core library. I think I have progressed the refactoring
work far enough that this is a useful thing to start.
To be clear this is *purely* a reorganisation of code. The new library
would remain licenced as now (GPL v2+openssl exception, unlike our
other libraries which are MIT) and all functionality would remain
The new library would use the core buildsystem however and be built as
part of the CI system.
The aim here is to have a clear identifiable boundary between what is
frontend code (which will remian in the netsurf project as now) and
what is core browser.
This move would emphaticaly *not* be an instant change, more a gradual
movement of functionality as it becomes clear where it belongs.
My first addition would probably be to move the gui_factory operation
table functionality and cause it to be used for the ns_register() very
early in all the frontends main() which should remove some of teh
issues ChrisY has experienced as fallout from my rcent refactors.
I want to get input on this from everyone, especailly from Chris and
Steve who have put up with my breaking their frontends with my
refactors and with whom I do not get to communicate with a great deal
on these things.
If we decide this split is a good idea I want to decide the library
name as well. If we follow the existing netsurf support library
convention it would be called "libns" and all exported functions would
be prefixed with "ns_"
This name fits reasonably well except it is a bit close to cocoa
library naming where everything is prefixed with "NS" (for nextstep),
This does not conflict (as nsurl etc. currently show) but might be
Other options are libnscore and libnsbrowser. However please remember
we prefix all exported functions with that name so nscore_ and
nsbrowser_ are a bit long. e.g. nsurl_ctreate() becomes nscore_url_create()
This is intended as a discussion start, if you are a current committer
please do comment!
On Fri, 16 May 2014 10:49:19 +0100, Vincent Sanders wrote:
> Right, I added
> which declares and documents
> nserror nsc_snptimet(char *str, size_t size, time_t *timep);
> int nsc_sntimet(char *str, size_t size, time_t *timep);
> Hope thats acceptable to everyone. They use the troublesome
> str(p|f)time on unix where present and less "correct" methods
> Printing and reading time_t directly appears to be a bit of a missing
> bit of the specification, hence the non-standard extensions.
It's working. I just committed the relevant bits to enable on the
Amiga frontend, although Jenkins appears to be stuck at the moment.