Graphical Web Browser

[koen]

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?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115252\"][{POST_SNAPBACK}][/a][/div]

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

Code: [Select]

koen@dominion:/data/build/oe/monotone/org.openembedded.dev/packages/gtk-webcore$ grep -rn LICENSE *.bb
osb-browser_0.5.0.bb:1:LICENSE = "GPL"
osb-browser_20050430.bb:3:LICENSE = "GPL"
osb-browser_20060212.bb:3:LICENSE = "GPL"
osb-jscore_0.5.0.bb:1:LICENSE = "GPL"
osb-jscore_20050430.bb:3:LICENSE = "GPL"
osb-jscore_20060212.bb:3:LICENSE = "GPL"
osb-nrcit_0.5.0.bb:2:LICENSE = "nokia"
osb-nrcit_20050430.bb:3:LICENSE = "nokia"
osb-nrcit_20060212.bb:3:LICENSE = "nokia"
osb-nrcore_0.5.0.bb:1:LICENSE = "GPL"
osb-nrcore_20050430.bb:3:LICENSE = "GPL"
osb-nrcore_20060212.bb:3:LICENSE = "GPL"
But both the author of webcore and the author of gpe-mini-browser (both nokia employees) as well as nokia itself know that Familiar and OpenZaurus ship binaries and are pretty happy with it.

[iamasmith]

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!


- Andy

[iamasmith]

*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

[iamasmith]

*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
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115273\"][{POST_SNAPBACK}][/a][/div]

  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...

ah well, that saves some time

- Andy

[iamasmith]

aaargh, JavaScriptCore uses some non posix pthread extension pthread_attr_get_np  it's not going to work without major hacking.

- Andy

[koen]

aaargh, JavaScriptCore uses some non posix pthread extension pthread_attr_get_np  it's not going to work without major hacking.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115282\"][{POST_SNAPBACK}][/a][/div]

If that fails you could try to build minimo, which is usually in a non-building state, but once notified Doug Turner fixes that within the hour

[iamasmith]

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.

- Andy

[pgas]

here are the tips given to me on #openzaurus to build gpe-minibroswer:
webcore : cvsdate 20050430 and two patches :
      http://www.kernelconcepts.de/~fuchs/oe/gdk-colorspace.diff
      http://www.kernelconcepts.de/~fuchs/oe/sto...e-loading.patch

(not specially related to open-bsd )

edit: It might have been on #gpe on irc.freenode.net

[iamasmith]

here are the tips given to me on #openzaurus to build gpe-minibroswer:
webcore : cvsdate 20050430 and two patches :
      http://www.kernelconcepts.de/~fuchs/oe/gdk-colorspace.diff
      http://www.kernelconcepts.de/~fuchs/oe/sto...e-loading.patch

(not specially related to open-bsd )
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115314\"][{POST_SNAPBACK}][/a][/div]

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.

here's the member function from kdelibs to show you...

299 void Collector::markCurrentThreadConservatively()
300 {
301     jmp_buf registers;
302     setjmp(registers);
303
304 #if __APPLE__
305     pthread_t thread = pthread_self();
306     void *stackBase = pthread_get_stackaddr_np(thread);
307 #elif defined(_WIN32) || defined(_WIN64)
308     NT_TIB *pTib;
309 #ifdef __GNUC__
310     __asm__("movl  %%fs:0x18,%0"
311             : "=r" (pTib)
312     );
313 #else
314     __asm {
315         MOV EAX, FS:[18h]
316         MOV pTib, EAX
317     }
318 #endif
319     void *stackBase = (void *)pTib->StackBase;
320 #else
321     static void *stackBase = 0;
322     static pthread_t stackThread;
323     pthread_t thread = pthread_self();
324     if (stackBase == 0 || thread != stackThread) {
325         pthread_attr_t sattr;
326 #ifdef HAVE_PTHREAD_NP_H
327         // e.g. on FreeBSD 5.4, neundorf@kde.org
328         pthread_attr_get_np(thread, &sattr);
329 #else
330         // FIXME: this function is non-portable; other POSIX systems may have different np alternatives
331         pthread_getattr_np(thread, &sattr);
332 #endif
333         // Should work but fails on Linux (?)
334         //  pthread_attr_getstack(&sattr, &stackBase, &stackSize);
335         pthread_attr_getstackaddr(&sattr, &stackBase);
336         assert(stackBase);
337         stackThread = thread;
338     }
339 #endif
340
341     int dummy;
342     void *stackPointer = &dummy;
343
344     markStackObjectsConservatively(stackPointer, stackBase);
345 }

EDIT:.... found a kludge for now..

/* OpenBSD workaround */
   stack_t stack_info;
   pthread_stackseg_np(thread,&stack_info);
   void *stackBase=stack_info.ss_sp;
....

- Andy

[iamasmith]

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.

- Andy

[iamasmith]

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.

- Andy

[mathemajikian]

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

[ZDevil]

Thanks! w3m is very sweat.

Next I will try to port Konquerer Embedded because it's (supposed to be) lighter and faster than Firefox.

[mathemajikian]

Thanks! w3m is very sweat.

Next I will try to port Konquerer Embedded because it's (supposed to be) lighter and faster than Firefox.

Konquerer Embedded is in the ports collection, but I think it's an older version. Look at www/konqueror-embedded