However, the licensing of the Webcore is on unusual territory being owned by Nokia (check the NRC* License files). Can you ever therefore distribure the webcore libraries on their own or is this and gpe-minibrowser only for people who build from source?

gtk+Webcore is just a port from webcore (apple) which is based on khtml (kde), the only shaky part is osb-nrcit:

OK Koen, nice little browser that, actually the browser here is mostly a wrapper for that great gtk-webcore project but still it does the business and is small.

One thing though.. the browser identifies itself as Netscape (try http://www.quirksmode.org/js/detect.html), since it is based upon Apple Webcore would it not be more sensible to make it report 'Safari' ? - it may stand a better chance of working with some of the more challenging sites.. better still being able to configure that would be great. - I suppose that's a question for the NRCore folk.

Anyway, I think I may build all that stuff for the OpenBSD on the Zaurus and see how it work on the target environment.

I have to say I was a little disappointed that the Atlantis browser wasn't open source, it looked like a more fully fledged browser (still small) but based on gtk-webcore. - license Freeware.. pah!

*sigh* autogen is using some new funky Gnuism with find... regex isn't common to UNIX find commands it seems... I think I need to implement a gfind command and maybe some other stuff

Man that's SPOOKY.

I thought I was going to have to implement a gfind based on the gnu source... however, just found a ports package of findutils for the gnu stuff and all the commands are prefixed g.... so gfind is in it along with gxargs etc...

I have minimo and it's ok but a little unstable and quite large compared with gpe-minibrowser and the gte-webcore.

I think I'm going to persevere with the gte-webcore and see if I can take that posix thread 'non posix' stuff out of kjs... I saw that there was some criticism inside the KDE libs sources (kjs comes from kde and is part of the JavaScriptCore) about the API not being portable and it should be 'fixed' so it may be that someone has patched this already for some task.

Thanks pgas but the nature of this issue doesn't effect Linux since Linux implements an alternate non-posix extension to pthreads that the kjs source in JavaScriptCore utilises if __linux is defined so you wouldn't have the issue that I'm working on anyway.

Basically the call sequence is used to get the stack address of the thread, something which isn't in the posix specification and sounds just the sort of extension that OpenBSD wouldn't want since it is potentially open to misuse. I took a look at version of kdelibs that this version of kjs was derived from and there is a critical comment inside the source about 'changing this since it isn't portable'. - I guess I will trawl for kdelibs patches next... someone porting to QNX or something else may have a workaround.

OK, I finally got gpe-minibrowser running on OpenBSD, however, there are some major glitches possibly related to the version of Gtk that we use on OpenBSD or possibly related to some of the ugly hacks that I made. - it may be that the non portable pthread call that I am using isn't returning anything in which case the problem is much harder to fix and the JavaScript core won't work well without it.

Anyway on the site that I can get (www.google.com ) it does look pretty, however, it doesn't look enough like Gecko engine to work with FCKEditor yet (needed for moinmoin, and tested from a desktop Linux build) and it runs at about 13Mb of memory usage.

So in summary on OpenBSD konq-e works better for this sort of thing.

Oh, btw if anyone decides to repeat this test set up PLENTY of swap before you build NRCore, it balooned to 130Mb of swap space when building the CSS stuff.

So I can afford to leave my Z building a little while longer and it looks like if you disable the MOZILLA_OFFICIAL and BUILD_OFFICIAL exports it may not sign the libraries which is where I was getting the segfault earlier.

This shlibsign program seems to be the bane of many mozilla builds with various builds even failing on i386 Linux systems too.

I'm trying with the prebuilt Mozilla having just stripped those tags out of the Makefile... odds on that Firefox will complain that the libraries aren't signed but I will try that first before cleaning and rebuilding since it takes ages to do that.

Even w3m doesn't compile (will try to fix it if I have time, or I'll test again in 1-2 weeks and correctly report it to the ports team), ok, it's not graphical, but at least it's a text browser I'm used to use.

www/w3m has been fixed and builds fine. Some graphical support can be obtained by building the inline image version. make show=FLAVORS