[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SimpleWebKit (was GNUstep Web browser (was Re: WebKit Bounty))

From: Nicola Pero
Subject: Re: SimpleWebKit (was GNUstep Web browser (was Re: WebKit Bounty))
Date: Wed, 7 Mar 2007 17:38:31 +0100 (CET)

Ehi, great stuff! :-)

Just a small comment: your GNUmakefile contains the line


Please remove it ... GNUSTEP_INSTALLATION_DIR is deprecated
as it won't work with FHS.

I suggest just leaving the installation domain unspecified in the GNUmakefile. 


PS: If you really want to specify the installation domain, you can add


before including common.make. ;-)

-----Original Message-----
From: Peter Cooper <address@hidden>
Sent: Wed, March 7, 2007 2:55 pm
To: Dr. H. Nikolaus Schaller <address@hidden>
Cc: Discuss GNUstep <address@hidden>, Riccardo <address@hidden>
Subject: Re: SimpleWebKit (was GNUstep Web browser (was Re: WebKit Bounty))


> Great! Maybe, you can share the GNUmakefile?

Here's one that compiles and installs SimpleWebKit as a library. A
framework is just as easy. I've also attached a small diff -c to one of
the files.

[snipped stuff about web browser being a bit out of scope]

> Well, WebKit is more a library - allowing to easily build a browser...

Yes. Agreed.

> There have been suggestions to rename it from SimpleWebKit - why not
> simply call it GNUstep-htmlengine? There is GNUstep-base, GNUstep-gui
> which is pretty descriptive of what the role of the library is. It is
> a base library, a GUI library and this one is a htmlengine.

I don't have strong opinions about this, but I would very much like the
compatibility of headers etc to exist. It'd be nice for Mac OS X
developers to be able to guess that the functionality exists in GNUstep,
which is a small plus point in retaining the name.

> Basically the approach is to parse HTML into a DOM tree (DOMHTML.h) -
> exactly as KHTML/WebKit does. Then, rendering is done top down from
> the WebHTMLView which has a single child, an NSTextView and the root
> of the DOM tree. The NSTextView finally renders an attributedString
> (well, an NSTextStorage), that is built from the DOM Tree. I.e.
> building this attributedString does half of the work and the other
> one is NSTextView.

Ok. And the rendering activity may create additional subviews? I can see
this being useful for optimisations to make fast fluid-layout redrawing
with the CSS box model possible. It'd be nice not to have to re-render the
entire document everytime the view is resized ;-)

> This allows the trick for NSAttributedString(Additions) to fetch the
> attributedString out of the WebView to e.g. convert to RTF.


> Now, adding CSS would be a similar approach. Either, the CSS
> description must load from a separate file first, or it is included
> in the DOM tree as <style> tags. So, the first step would be to parse
> the CSS into an DOMCSS tree. As soon as this is available, the DOM to
> attributedString conversion can use it to return a well formatted
> string. Finished loading of an external CSS must trigger the
> rendering to be repeated since layout and style may have changed.
> This is a bahaviour that you can see sometimes with Safari on a slow
> connection - firstly, you get a page with raw text and then the
> background, tables, images and formats come in.

Cool. Do you want me to do translation of the DOM level 2 IDL files into
objc headers using the same approach (compatible names) as WebKit? Should
be achievable before the weekend.


Discuss-gnustep mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]