kyllikki

As I mentioned elsewhere, we have no windows frontend maintainer so feature development specific to windows does not currently happen.

The win port uses windows 2000 compatible GDI calls and I imagine this is the cause for GIF flickering, SVG not rendering and truetype fonts not being used.

The core browser functionality does support javascript, however there are thousands of DOM bindings and our progress in implementing them all is slow.

We are a very small team and rely on maintainers to actively look after a frontend. For example Chris does a brilliant job keeping the Amiga frontend in shape and I keep GTK going. Other frontends like Windows, RISC OS and Atari lack a maintainer altogether and are kept going purely through inertia.

Unfortunately the Mac OS X frontend became unmaintained some time ago and eventually stopped working altogether which resulted in its removal from the master branch and hence releases.

There was some activity by Sven earlier in the year ( http://source.netsurf-browser.org/netsurf.git/log/?h=svenw/c... ) but it was not ready to be included and I think he lost interest again.

For those having issues please can you try our CI builds from https://ci.netsurf-browser.org/builds/ and if you are still experiencing problems a bug report on https://bugs.netsurf-browser.org would be appreciated.

The browser is a little limited in its javascript support (and hence rendering of a lot of modern sites) but it should not crash in general operation.

I enjoyed building this computer a lot. But Ben has not yet done a schematic set. so I made my own in kicad and published them https://github.com/kyllikki/eda-designs/tree/master/SAP-BE

The PDF is also there if you do not want to install kicad

I did not use it because it was an unverified python script with a bunch of dependencies, as a rule I generally do not like executing untrusted code without at least a basic review.

As you mentioned, the Perl script was 100 lines and was easier at that moment in time to integrate than to review the python.

Of course once the python client has been reviewed perhaps it would be a more general solution.

Transifex have extended the format and allow resources to be UTF-8 encoded (see http://help.transifex.com/features/formats.html#java-propert... ) however the importer does not correctly cope with single quote characters, backslash n (newline) and several other characters being encoded when they ought to be (as per the document you referenced which I also used to begin with ;-)

If you look at the script Vivek wrote http://git.netsurf-browser.org/netsurf.git/tree/utils/split-... he clearly documents the odd importer issues which is why we called it the transifex resource format and not Java resource format ;-)

The gettext PO file format does indeed provide many other features, I do not disagree, but there does seem to be an over reliance on it within the platforms I looked at.

The format does have some pretty major drawbacks too, like the msgid can become "fuzzy" which leads to a differing set of issues related to the unique keying between translations.

It also tends to lead to developers English (C locale if you like) being selected as the default language and it turns out developers like myself are sloppy and sometimes produce barely parsable messages.

Your remaining points are really valuable to someone inexperience in the field, like myself, so thanks for pointing those out.

It is interesting you call out cultural issues, did you have any specific examples?

I think the Boston Viridis falls into the "commercial blade server" category and as suggested in the conclusion is how it should be done if you were not using existing dev boards.

Is that an invite to show me round Cambridge MakeSpace? ;-) I was thinking about the open evening on tuesday but it is very inconvenient.

hey you could have posted the link to my whole posting ;-)

http://vincentsanders.blogspot.co.uk/2012/11/another-netsurf...