On Fri, 21 Dec 2012 14:20:21 +0100, Ole wrote:
> I have created a branch where you can interactively edit the Choices by
> going to "about:config" URL.
> The reason:
> I had to re-implement the atari settings dialog but I was to lazy to do
> all that.
I'm not sure the reasoning behind implementation is the correct one,
but I do like the concept, especially for power users and developers
who need to change advanced options during run-time.
I have a couple of comments:
1. It would be nice if the options that have particular effects for
integer values, were a drop-down choice rather than an integer gadget
(this stop sthe users selecting out-of-range values and makes it clear
what the choice is going to do). eg. http_proxy_auth would show the
options "No proxy", "NTLM authentication".
1b. As above but for fields expecting filenames, paths and colours
should show something appropriate to make the choice easier and avoid
errorneous input, although these might be tricky to implement given
the constraints of HTML.
2. I'm not sure if there are any options that are dangerous to change
during run-time, but if so there should be the possibility of making
Ole <ole(a)monochrom.net> wrote:
> I do not agree on the idea that the treeview doesn't look "native".
> That's mostly because of it's background colour ;)
The background colour is meant to be set by the front end.
See the gui_system_colour_* stuff.
Michael Drake (tlsa) http://www.netsurf-browser.org/
I have created a branch where you can interactively edit the Choices by
going to "about:config" URL.
I had to re-implement the atari settings dialog but I was to lazy to do
At least the framebuffer version can also benefit by this branch.
It still requires to be secured. I though about an "random" token which
get's generated on each
delivery of about:config - the token on submit must match the last
A screen-shot is attached for those who can not imagine what I'm
Is there any chance to have it merged into master when it is secured?
I've just recreated my cross-compilation setup for NetSurf (currently on
Ubuntu 10.04, although that's likely to be changing soon), and have been
reading the BUILDING-ROcross documentation supplied in the Docs folder of
the source. I'd like to update that, having had a read of the more generic
build method given in
but am a little concerned that I've missed the point of one of the steps.
The Wiki page advises setting up the $PREFIX as follows
Is there any specific reason for doing it this way in a cross-compilation
environment, which I've missed? Given that I then had to manually install
the libraries from workspace/inst into the GCCSDK structure, could that be
or would doing so break some other aspect of the new build structure that
expects the files to also be in workspace/inst?
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
I think I found a bug in the dom_string_isequal function in core/string.c.
The attached testcode (isequal-test.c) will generate a segfault.
The code works as expected (at least for me) after attached patch is
I noticed NS didn't handle the Back/Forward keys I have on my thinkpad...
Actually I sometimes complain about those as they are quite misplaced
(above left and right arrow), but still on some keyboards they could be
So I added code to support those in the branch mmu_man/xf86keys.