WebKit Bounty

[Jesse Ross]

There has been a lot of discussion as of late about getting a well-
integrated web browser/web view working in GNUstep. That's been a
desire of mine for the past few years, and, even with the
availability of Apple's WebKit and the release of GCC 4.1 with
support for Objective-C++, we still don't have a working solution.
So, here is my proposal:

I would like to start a bounty for the port of WebKit to GNUstep. In
order to receive the bounty, the following requirements must be met:

- The port should use the latest code (as of 2006.02.28) from the
WebKit Subversion repository as located at http://webkit.org/
- All patches must be submitted back to the original codebase. We
would like to avoid a fork by getting GNUstep support in WebKit proper.
- Along with the port of WebKit itself, the potential bounty
recipient must also include a GORM palette for embedding web views in
GNUstep applications.

Upon completion of the above items and a code review by selected
third-party developers, the bounty will be disbursed within 60 days
after code delivery. The amount of the bounty is $500 USD -- if
others would like to offset some of my personal cost, or contribute
to the bounty, please contact me and I will coordinate the transactions.

Good luck and thanks in advance to all who participate!

Jesse Ross

[Jesse Ross]

That should have been dated 2007.02.28 ;)

J.

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Chris B. Vetter]

On 3/2/07, Jesse Ross <gnu...@jesseross.com> wrote:
[...]

> - The port should use the latest code (as of 2006.02.28) from the
> WebKit Subversion repository as located at http://webkit.org/

The WebKit team is moving away from Objective-C to C++ for *cough*
"making the code more portable."

A while back I was working on porting WebKit to GNUstep but got stuck
with JavaScriptCore's bindings, since these rely heavily on
CoreFoundation.
Since I couldn't get the current CoreFoundation working, I tried
CF-Lite, which didn't work with JavaScriptCore (due to missing
functionality provided by the 'real' CoreFoundation).

You could probably do without the bindings (given that there's a
GTK-port of WebKit which apparently doesn't use it either) but will
come away with a somewhat limeted functionality.

> - All patches must be submitted back to the original codebase. We
> would like to avoid a fork by getting GNUstep support in WebKit proper.

WebKit was ported to GTK in fall 2004 (if memory serves) and still
hasn't been fully integrated...

> - Along with the port of WebKit itself, the potential bounty
> recipient must also include a GORM palette for embedding web views in
> GNUstep applications.

You will first have to write a full engine, as the current ones (last
time I checked) are for OSX, GDK and WX only.

> Upon completion of the above items and a code review by selected

Keep in mind that the whole SVN checkout is roughly about 550MB of
code... WebKit uses Xcode and/or Bakefiles. So you'll need to make
yourself familiar with these and either need to figure out how they
work with GNUstep or need to write each and every GNUmakefile from
scratch.

So, basically what I'm saying is that porting WebKit is a HUGH venture.

--
Chris

[Rogelio Serrano]

On 3/2/07, Chris B. Vetter <chris....@gmail.com> wrote:

> Keep in mind that the whole SVN checkout is roughly about 550MB of
> code... WebKit uses Xcode and/or Bakefiles. So you'll need to make
> yourself familiar with these and either need to figure out how they
> work with GNUstep or need to write each and every GNUmakefile from
> scratch.
>

OMG! no way! Thats BIG!

I think i would rather start playing with expat and focus on xhtml and
other xml stuff.

> So, basically what I'm saying is that porting WebKit is a HUGH venture.
>
> --
> Chris
>
>

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>

--
the thing i like with my linux pc is that i can sum up my complaints in 5 items

[Chris B. Vetter]

On 3/2/07, Rogelio Serrano <rogelio...@gmail.com> wrote:
> On 3/2/07, Chris B. Vetter <chris....@gmail.com> wrote:
> > Keep in mind that the whole SVN checkout is roughly about 550MB of
> > code... WebKit uses Xcode and/or Bakefiles. So you'll need to make

[...]

> OMG! no way! Thats BIG!
> I think i would rather start playing with expat and focus on xhtml and
> other xml stuff.

I'm not sure how recent my checkout is (some time around December, I
think) and how much of it IS actual code. There's tons of testing
stuff as well. But still, even if you divide it by 2, it's a lot...

--
Chris

[Camille Bourgoin]

In my opinion, a web framewok is absolutely essential. What is the
best solution ? Starting a Framework from scratch ? Using a preexistent
lightweight engine ?

I'm not a programmer (I'm a philosopher and I'm a poor beginner in
sh/lisp/C/objective-c who learn a lot but can't doing nothing :(
), then I don't realize correctly the amount of work of porting a
Framework like WebKit... Is the project unmanageable ?

--
Deux augures ne peuvent se regarder sans rire.
-+- Cicéron (106-43 avant JC) -+-

[Chris B. Vetter]

On 3/2/07, Camille Bourgoin <monsieur...@gmail.com> wrote:
> In my opinion, a web framewok is absolutely essential. What is the

Yes.

> best solution ? Starting a Framework from scratch ? Using a preexistent
> lightweight engine ?

I honestly do not know what the best solution would be. However,
starting from scratch probably isn't as there already is work to draw
from.

The beauty of Objective-C is it's expandability. So I guess the best
way would be to write a browser application as a stand-alone (i.e.
WITHOUT a build-in WWW engine) providing just the basics, that is, a
window (with tabs) that holds the documents (i.e. web pages) and the
navigation bar. Everything else is implemented via "plugins."

That way, you could use an engine based, say, off libwww, while
another group works on porting WebKit, that can then replace the 'old'
engine, when it's done. You could even provide both and let the user
pick his preferred engine through a preference setting.

> I'm not a programmer (I'm a philosopher and I'm a poor beginner in
> sh/lisp/C/objective-c who learn a lot but can't doing nothing :(
> ), then I don't realize correctly the amount of work of porting a
> Framework like WebKit... Is the project unmanageable ?

I don't think so, but it will require a LOT of work.

--
Chris

[David Wetzel]

Hi Folks,

Am 02.03.2007 um 09:24 schrieb Chris B. Vetter:

>
> A while back I was working on porting WebKit to GNUstep but got stuck
> with JavaScriptCore's bindings, since these rely heavily on
> CoreFoundation.
> Since I couldn't get the current CoreFoundation working, I tried
> CF-Lite, which didn't work with JavaScriptCore (due to missing
> functionality provided by the 'real' CoreFoundation).

Maybe spidermonkey is a good thing? SpiderMonkey is the code-name for
the Mozilla's C implementation of JavaScript.

http://www.mozilla.org/js/spidermonkey/

Dave

--
_ _
_(_)(_)_ David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG,
_/ \_ Fax +49 33056 82835 Phone +49 33056 82834
(______) http://www.turbocat.de/

[Chris B. Vetter]

On 3/2/07, David Wetzel <da...@turbocat.de> wrote:
> Maybe spidermonkey is a good thing? SpiderMonkey is the code-name for
> the Mozilla's C implementation of JavaScript.
> http://www.mozilla.org/js/spidermonkey/

Since WebCore and WebKit draw upon header files of JavaScriptCore, you
will then have to figure out how to to implement these based on
SpiderMonkey...

I don't think that's worth the effort. Especially since you won't know
from the start whether these two projects will work together.

--
Chris

[Rogelio M. Serrano Jr.]

Camille Bourgoin wrote:
> On 2007-03-02 09:39:50 +0100 Chris B. Vetter <chris....@gmail.com> wrote:
>
>
>> On 3/2/07, Rogelio Serrano <rogelio...@gmail.com> wrote:
>>
>>> On 3/2/07, Chris B. Vetter <chris....@gmail.com> wrote:
>>>
>>>> Keep in mind that the whole SVN checkout is roughly about 550MB of
>>>> code... WebKit uses Xcode and/or Bakefiles. So you'll need to make
>>>>
>> [...]
>>
>>> OMG! no way! Thats BIG!
>>> I think i would rather start playing with expat and focus on xhtml and
>>> other xml stuff.
>>>
>> I'm not sure how recent my checkout is (some time around December, I
>> think) and how much of it IS actual code. There's tons of testing
>> stuff as well. But still, even if you divide it by 2, it's a lot...
>>
>>
>

> In my opinion, a web framewok is absolutely essential. What is the

> best solution ? Starting a Framework from scratch ? Using a preexistent
> lightweight engine ?
>
>

Its hard to say really. Ideally a lightweight engine would be a better
start if one is available. I think the only way is to try and fail. Se
we find out which one will do.

A start from scratch is better done by someone who has experience with
current web frameworks if one wants to catch up with currrent web
technology. But if emerging web technology is the focus then anyone with
a good understanding of xml will probably be able to create one from
scratch.

Maybe if we could agree on an easy to implement subset then that might
be something.

I think the second option has higher value in the long run since the
widespread adoption of web technology in areas other than the web seems
to be the trend. I think DO over REST would be a very nice thing to have.

> I'm not a programmer (I'm a philosopher and I'm a poor beginner in
> sh/lisp/C/objective-c who learn a lot but can't doing nothing :(
> ), then I don't realize correctly the amount of work of porting a
> Framework like WebKit... Is the project unmanageable ?
>
>
>

I dont think so. But thats only me. There was initial success in
porting webkit but im not sure if it is still active. And my efforts to
help was ineffective.

[Chris B. Vetter]

On 3/2/07, Rogelio M. Serrano Jr. <rog...@smsglobal.net> wrote:
[...]

> > I'm not a programmer (I'm a philosopher and I'm a poor beginner in
> > sh/lisp/C/objective-c who learn a lot but can't doing nothing :(
> > ), then I don't realize correctly the amount of work of porting a
> > Framework like WebKit... Is the project unmanageable ?
> I dont think so. But thats only me. There was initial success in
> porting webkit but im not sure if it is still active. And my efforts to
> help was ineffective.

You're probably referring to GSWebKit. Work has halted, as far as I
know, so it's pretty outdated by now.

It used to work reasonably well, but doesn't anymore (at least when
compiled with gcc-4.x). Not sure why. But I can only load an initial
page. Whenever I try to enter a new location or try a link within the
page, GSWebKit throws an exception and my browser crashes.

--
Chris

[Rogelio M. Serrano Jr.]

Chris B. Vetter wrote:
> On 3/2/07, Camille Bourgoin <monsieur...@gmail.com> wrote:

>> In my opinion, a web framewok is absolutely essential. What is the
>

> Yes.

>
>> best solution ? Starting a Framework from scratch ? Using a preexistent
>> lightweight engine ?
>

> I honestly do not know what the best solution would be. However,
> starting from scratch probably isn't as there already is work to draw
> from.
>
> The beauty of Objective-C is it's expandability. So I guess the best
> way would be to write a browser application as a stand-alone (i.e.
> WITHOUT a build-in WWW engine) providing just the basics, that is, a
> window (with tabs) that holds the documents (i.e. web pages) and the
> navigation bar. Everything else is implemented via "plugins."
>
> That way, you could use an engine based, say, off libwww, while
> another group works on porting WebKit, that can then replace the 'old'
> engine, when it's done. You could even provide both and let the user
> pick his preferred engine through a preference setting.
>

I like this idea...

I think iterm is structured this way.

>> I'm not a programmer (I'm a philosopher and I'm a poor beginner in
>> sh/lisp/C/objective-c who learn a lot but can't doing nothing :(
>> ), then I don't realize correctly the amount of work of porting a
>> Framework like WebKit... Is the project unmanageable ?
>

[Dennis Leeuw]

This discussion pops up once in a while, the fact that we want a GNUstep
web browser. From a non-programmer point of view, I would like to make
the following comments:

Every time this discussion pops up people are looking for short cuts.
Basing coding on existing projects, which from an open source point of
view, might be logical, but, from that same open source point of view,
we are not in a hurry. We can take the time to build a complete
web-engine from scratch, as long as we build a better engine.

And that is my point. Time is not the issue, it has to be better. There
are a lot of web browsers around and just a couple of engines. So we
could steal ideas and code snippets and prove that Objective-C and
GNUstep are a better base for an engine then anything else around.

And if we are really that good, Apple will use the newly written,
GNUstep based engine for their next release of Safari ;)

Prove those C++ coders wrong and make the world (wide web) a better place.

With kind regards,

Dennis Leeuw

[Helge Hess]

On Mar 2, 2007, at 10:44, David Wetzel wrote:
> Maybe spidermonkey is a good thing? SpiderMonkey is the code-name
> for the Mozilla's C implementation of JavaScript.
>
> http://www.mozilla.org/js/spidermonkey/

SpiderMonkey is a good thing, but two things must be kept in mind:
a) as already written by others its probably not worth the effort to
adopt WebKit to use it
b) I think Mozilla is actively working on a completely new
implementation,
so SpiderMonkey might become deprecated.

Having said that, if someone wants to start it nevertheless, our
JavaScript/ObjC bridge might be a pool for ideas:
http://svn.opengroupware.org/SOPE/trunk/Recycler/NGJavaScript/

Greets,
Helge
--
Helge Hess
http://www.helgehess.eu/

[Camille Bourgoin]

Chris B. Vetter has a great idea, I think, when he say that with
Objective-c we can simply separate the engine from the web-browser,
solution who offer the possibility to chose the engine to the user,
and offer to the developpers a clear tasks division : teams work on
web-browsers, and others on engines.

It is possible to do a very extensible web-browser : we can choose
the engine ; we can add tools simply ; we can use all the power
of Services etc. The power of Firefox are his extensions. With the
GNUstep Framework we can go further in exensibility.

"We are not in hurry ?" Maybe. You are right. But I think it's also
a good idea to port rapidly a simple engine (or create it) in order
to provide rapidly a solution and attract some developpers (and users).

[Graham J Lee]

On 2 Mar 2007, at 08:34, Rogelio Serrano wrote:

> On 3/2/07, Chris B. Vetter <chris....@gmail.com> wrote:
>
>> Keep in mind that the whole SVN checkout is roughly about 550MB of
>> code... WebKit uses Xcode and/or Bakefiles. So you'll need to make

>> yourself familiar with these and either need to figure out how they
>> work with GNUstep or need to write each and every GNUmakefile from
>> scratch.
>>
>

> OMG! no way! Thats BIG!
>
> I think i would rather start playing with expat and focus on xhtml and
> other xml stuff.

That seems like a great approach, as it could easily be employed in
contexts outside [x]HTML, such as DocBook. In fact, an XSLT-based
doc viewer would be wond'rous to behold :-).

In another fact, a poor man's version of the above would be
comparatively simple...transform the source XML file into XSL-FO,
then process *that* into RTF/RTFD and finally load into an
NSAttributedString. I don't remember seeing any FO processors which
weren't in Java though...and the above process might be quite expensive.

Graham.

[Michael Thaler]

Hi,

> OMG! no way! Thats BIG!
> I think i would rather start playing with expat and focus on xhtml and
> other xml stuff.

There is also WebKitQt which is a port of WebKit to Qt. It can be built with WebKit/WebKitTools/Scripts/build-webkit and there is QtLauncher, a simple example browser. There is no real full-featured browser using WebKitQt yet, but QtLauncher displays web pages quite well.

I have never even looked at the source code of WebKit, but if it is possible to port it to Qt, shouldn't it also be possible to port it to gnustep? I know WebKit is a fork of khtml, the KDE rendering engine, but as far as I know, WebKit abstracted away Qt/KDE dependicies. So if it is possible to port WebKit to Qt, why is it so hard to port it to gnustep?

Greetings,
Michael

[Rogelio Serrano]

On 3/2/07, Michael Thaler <michael...@ph.tum.de> wrote:

> There is also WebKitQt which is a port of WebKit to Qt. It can be built with WebKit/WebKitTools/Scripts/build-webkit and there is QtLauncher, a simple example browser. There is no real full-featured browser using WebKitQt yet, but QtLauncher displays web pages quite well.
>
> I have never even looked at the source code of WebKit, but if it is possible to port it to Qt, shouldn't it also be possible to port it to gnustep? I know WebKit is a fork of khtml, the KDE rendering engine, but as far as I know, WebKit abstracted away Qt/KDE dependicies. So if it is possible to port WebKit to Qt, why is it so hard to port it to gnustep?
>

Webkit is mostly c++. Thats why.

> Greetings,
> Michael

[Chris Vetter]

On 2007-03-02 11:29:08 +0100 Michael Thaler <michael...@ph.tum.de>
wrote:

> I have never even looked at the source code of WebKit, but if it is
> possible
> to port it to Qt, shouldn't it also be possible to port it to
> gnustep? I know
> WebKit is a fork of khtml, the KDE rendering engine, but as far as I
> know,
> WebKit abstracted away Qt/KDE dependicies. So if it is possible to
> port
> WebKit to Qt, why is it so hard to port it to gnustep?

I never said it's hard, I said it's a hugh venture.

WebKit basically consists of the following frameworks that need to be
ported. Let me break it down:

- JavaScriptCore
Almost compiles out of the box, however, its bindings heavily depend
on CoreFoundation which
would have to be ported first (or go with the 'penalty' of lacking the
provided features)

- JavaScriptGlue
Needs CoreServices, which isn't available (AFAIK), again you could
probably do without. And I'm
not even sure this is really needed...

- WebCore
This basically is KHTML. You will need to write a graphics engine
(there already engines for GDK,
Win, QT, Cairo and one for Mac, using CoreGraphics, which again isn't
available)
Porting WebCore is the biggest task.

- WebKit
This one adds Views, Panels, History, etc. This is basically the stuff
you would see in InterfaceBuilder.
Technically, this could be considered 'goodies' or a 'would be nice to
have as well.'

--
Chris

[Yen-Ju Chen]

I did some research on tkhtml (http://tkhtml.tcl.tk/) before.
It is small, mostly in C.
Then I gave up for other things.

Yen-Ju

>
> --
> Chris

[Andrew Satori]

It is worth mentioning that OmniWeb started life as a Web Browser on
NeXT that was well regarded, and used it's own internal OBjective C
HTML rendering engine. With version 4.5 on the Mac, they abandonded
their own HTML code and adopted WebKit..

/* Satori & Associates, Inc.
************************************************/

On Mar 2, 2007, at 5:49 AM, Dennis Leeuw wrote:

> This discussion pops up once in a while, the fact that we want a
> GNUstep web browser. From a non-programmer point of view, I would
> like to make the following comments:
>
> Every time this discussion pops up people are looking for short
> cuts. Basing coding on existing projects, which from an open source
> point of view, might be logical, but, from that same open source
> point of view, we are not in a hurry. We can take the time to build
> a complete web-engine from scratch, as long as we build a better
> engine.
>
> And that is my point. Time is not the issue, it has to be better.
> There are a lot of web browsers around and just a couple of
> engines. So we could steal ideas and code snippets and prove that
> Objective-C and GNUstep are a better base for an engine then
> anything else around.
>
> And if we are really that good, Apple will use the newly written,
> GNUstep based engine for their next release of Safari ;)
>
> Prove those C++ coders wrong and make the world (wide web) a better
> place.
>
> With kind regards,
>
> Dennis Leeuw
>

> Rogelio M. Serrano Jr. wrote:
>> Chris B. Vetter wrote:
>>> On 3/2/07, Camille Bourgoin <monsieur...@gmail.com> wrote:
>>>> In my opinion, a web framewok is absolutely essential. What is the
>>> Yes.
>>>
>>>> best solution ? Starting a Framework from scratch ? Using a
>>>> preexistent
>>>> lightweight engine ?
>>> I honestly do not know what the best solution would be. However,
>>> starting from scratch probably isn't as there already is work to
>>> draw
>>> from.
>>>
>>> The beauty of Objective-C is it's expandability. So I guess the best
>>> way would be to write a browser application as a stand-alone (i.e.
>>> WITHOUT a build-in WWW engine) providing just the basics, that is, a
>>> window (with tabs) that holds the documents (i.e. web pages) and the
>>> navigation bar. Everything else is implemented via "plugins."
>>>
>>> That way, you could use an engine based, say, off libwww, while
>>> another group works on porting WebKit, that can then replace the
>>> 'old'
>>> engine, when it's done. You could even provide both and let the user
>>> pick his preferred engine through a preference setting.
>>>
>> I like this idea...
>
>
>
>

[Peter Cooper]

Jesse has proposed a bounty of $500 for the WebKit port to GNUstep and
getting the patches back into the webkit.org svn tree.

I'd find this very useful, and it'd be nice to finally get a fully-GNUstep
desktop environment, let alone the opportunities for a richer application
environment.

It's going to be a non-trivial activity, so I've offered to match his
$500. I'm in favour of having some sensible sunset clause on the bounty,
but I'll leave that to Jesse to think about.

Regards

Peter

[Jesse Ross]

> I'm in favour of having some sensible sunset clause on the bounty,
> but I'll leave that to Jesse to think about.

I realize that it's going to be a lot of work, but, given Peter's
suggestion, let's have the bounty active until September 1st, 2007,
giving prospective bounty recipients 6 months to work on the port.

J.

[h...@computer.org]

> are a lot of web browsers around and just a couple of engines. So we
> could steal ideas and code snippets and prove that Objective-C and
> GNUstep are a better base for an engine then anything else around.

> >> The beauty of Objective-C is it's expandability. So I guess the best

> >> way would be to write a browser application as a stand-alone (i.e.
> >> WITHOUT a build-in WWW engine) providing just the basics, that is, a
> >> window (with tabs) that holds the documents (i.e. web pages) and the
> >> navigation bar. Everything else is implemented via "plugins."

That can be done with any rendering engine as long as it uses a
compatible
implementation of WebView (and perhaps WebFrame).

> Prove those C++ coders wrong and make the world (wide web) a better place.

What I (and all those who have attended the FOSDEM meeting) always
wonder,
is that the same ideas come up again and again.

I think it is worth to mention SimpleWebKit here - a rough
implementation of
WebView, WebFrame, WebFrameView, WebDataSource etc. - completely
written
in Objective-C without any C++. The reason is that it must cross-
compile
on gcc 2.95.3 for some ARM processors.

Here is the source code to look at: http://www.quantum-step.com/download/sources/mySTEP/SimpleWebKit/

It is not complete but does HTML parsing - HTML rendering is not yet
available since I don't completely understand
the interaction between WebHTMLDocumentRepresentation, DOMHTML and the
WebHTMLView classes.

All the other parts work - loading an URL, notifying end of load,
handling different MIME etc.

So, volunteers to participate are very welcome!

@Jesse Ross:

One question is of course if this will satisfy the Bounty conditions -
it is NOT WebKit ported, it is a compatible reimplementation.

rgds, Nikolaus

[Markus Hitter]

Am 02.03.2007 um 17:32 schrieb Chris Vetter:

> - WebCore
> [...] there already engines for [...] Cairo

Isn't this everything one needs? If NSOpenGLView is usable without an
Obj-C based OpenGL implementation, NSWebView doesn't require an Obj-C
implementation either, right?

En passant, this would confirm GNUstep's Cairo backend as backend of
the future.

Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/

[Rogelio M. Serrano Jr.]

Can we make it handle xml and xslt?

> All the other parts work - loading an URL, notifying end of load,
> handling different MIME etc.
>
> So, volunteers to participate are very welcome!
>
>
> @Jesse Ross:
>
> One question is of course if this will satisfy the Bounty conditions -
> it is NOT WebKit ported, it is a compatible reimplementation.
>
> rgds, Nikolaus
>

[h...@computer.org]

>
> Can we make it handle xml and xslt?

Yes - we can do everything we can imagine.

As long as there are volunteers...

[Michael Thaler]

Hi,

> I think it is worth to mention SimpleWebKit here - a rough
> implementation of
> WebView, WebFrame, WebFrameView, WebDataSource etc. - completely
> written
> in Objective-C without any C++. The reason is that it must cross-
> compile
> on gcc 2.95.3 for some ARM processors.
>
> Here is the source code to look at:
> http://www.quantum-step.com/download/sources/mySTEP/SimpleWebKit/
>
> It is not complete but does HTML parsing - HTML rendering is not yet
> available since I don't completely understand
> the interaction between WebHTMLDocumentRepresentation, DOMHTML and the
> WebHTMLView classes.

What makes writing HTML parsers/rendering engines really difficult is not
parsing correct HTML and showing it. The problem is parsing/showing incorrect
HTML. Apple spends a lot of resources testing WebKit with a lot of buggy web
pages and make them show reasonably well. Some KDE people consider using
WebKit in KDE4 because it is a waste of resources to duplicate all this work.

Personally I think there is absolutely no point in writing some simple HTML
parser/rendering engine that doesn't show buggy web pages reasonably well
(except as an academic excercise). Who wants to use something like this?

And whats the point in writing a HTML parser/rendering enginge in Objective-C
anyway? It is absolutely no difference for the user and it is even no big
difference for developers because most of them will never touch the HTML
parser/renderer code anyway.

Greetings,
Michael

[Thom Cherryhomes]

My thoughts EXACTLY!

-Thom

[Gregory John Casamento]

Micheal,

I completely agree, It would be foolish not to leverage all of the work by the KHTML and WebKit teams. GNUstep doesn't need to maintain it's own HTML rendering engine. It's too big and time consuming and we have more important things to focus on.

Later, GJC
--
Gregory Casamento

[Riccardo]

Hi,

On Friday, March 2, 2007, at 09:29 PM, h...@computer.org wrote:

> I think it is worth to mention SimpleWebKit here - a rough
> implementation of
> WebView, WebFrame, WebFrameView, WebDataSource etc. - completely
> written
> in Objective-C without any C++. The reason is that it must cross-
> compile
> on gcc 2.95.3 for some ARM processors.

I think it is a pretty good idea. If done well it should end up in a
cleaner implementation than apple's and also more manageable. Of course
it will never reach the completeness of WebKit, since even WebKit pales
compared to Gecko. But it could end up being more portable, more
efficient and what is good even a good option since you say ti is a
reimplementation. As I read it, one browser could use one or the other
without big effort.
It could be used in a light-browser as well as in applications were an
embedded HTML/XHTML engine is needed.

Of course it should en handling real-world pages decently, but before
worrying of that (links does it and even dillo improved a little) it
should display correct pages correctly. The rest is added "burden"
actually.

Would you consider signing FSF and making it LGPL available in gnustep?

-Ric

[Thom Cherryhomes]

*shakes-head*

*walks-away*

On 3/3/07, Riccardo <mul...@ngi.it> wrote:
> Hi,
>
> On Friday, March 2, 2007, at 09:29 PM, h...@computer.org wrote:
>

> > I think it is worth to mention SimpleWebKit here - a rough
> > implementation of
> > WebView, WebFrame, WebFrameView, WebDataSource etc. - completely
> > written
> > in Objective-C without any C++. The reason is that it must cross-
> > compile
> > on gcc 2.95.3 for some ARM processors.
>

> I think it is a pretty good idea. If done well it should end up in a
> cleaner implementation than apple's and also more manageable. Of course
> it will never reach the completeness of WebKit, since even WebKit pales
> compared to Gecko. But it could end up being more portable, more
> efficient and what is good even a good option since you say ti is a
> reimplementation. As I read it, one browser could use one or the other
> without big effort.
> It could be used in a light-browser as well as in applications were an
> embedded HTML/XHTML engine is needed.
>
> Of course it should en handling real-world pages decently, but before
> worrying of that (links does it and even dillo improved a little) it
> should display correct pages correctly. The rest is added "burden"
> actually.
>
> Would you consider signing FSF and making it LGPL available in gnustep?
>
> -Ric
>
>
>

[Rogelio M. Serrano Jr.]

Michael Thaler wrote:
> What makes writing HTML parsers/rendering engines really difficult is not
> parsing correct HTML and showing it. The problem is parsing/showing incorrect
> HTML. Apple spends a lot of resources testing WebKit with a lot of buggy web
> pages and make them show reasonably well. Some KDE people consider using
> WebKit in KDE4 because it is a waste of resources to duplicate all this work.
>
> Personally I think there is absolutely no point in writing some simple HTML
> parser/rendering engine that doesn't show buggy web pages reasonably well
> (except as an academic excercise). Who wants to use something like this?
>
> And whats the point in writing a HTML parser/rendering enginge in Objective-C
> anyway? It is absolutely no difference for the user and it is even no big
> difference for developers because most of them will never touch the HTML
> parser/renderer code anyway.
>
> Greetings,
> Michael
>
>
>

I dont think this is enough reason to invent a new ugly language. So we
can render broken pages properly. For apple maybe.

Duplication cannot be avoided. Would you rather integrate c++, ada,
fortran, .net, java and cobol in obj-c so we can avoid duplicating what
some super project in these language have done?

If html is so easy to do wrong and so hard to handle then we put a
bullet in the s*****'s head and move on.

[Christopher Armstrong]

Hi

> I completely agree, It would be foolish not to leverage all of the work
> by the KHTML and WebKit teams. GNUstep doesn't need to maintain it's own
> HTML rendering engine. It's too big and time consuming and we have more
> important things to focus on.

And on that note, you'll need some kind of CoreFoundation, which is used
in some parts of JavascriptCore/WebCore in order to avoid mixing
(mostly) C++ code with Objective-C calls. Considering that Apple's
CoreFoundation is *generally* just a C implementation of GNUstep base,
I've been working on a implementation that pretty much wraps what is in
GNUstep base already.

Most of the APIs map one-to-one, so its generally just a case of
declaring a prototype and calling the GNUstep base method. Not all APIs
match, however, and there is some things we cannot support easily (such
as custom allocators), but we can come pretty close, and fill in the
gaps elsewhere with either custom implementations or an implementation
inside GNUstep Base.

Find a start effort at:
http://carmstrong.fastmail.com.au/CoreFoundation-20070304-final.tgz

Also note this is horribly incomplete (I've only just started
prototyping the CFString/NSString functions) but serves as an example of
what I mean. I'm using the same idea that was being explored in the old
GNUstep WebKit before it went inactive.

Cheers
Chris

--
Christopher Armstrong
carmstrong ^^AT^ fastmail dOT com /Dot/ au

[Gregory John Casamento]

Rogelio,

> I dont think this is enough reason to invent a new ugly language. So we
> can render broken pages properly. For apple maybe.

Invent a new ugly language??? Heh. No one is doing anything of the sort. ObjC++ has been around for a while.

> Duplication cannot be avoided. Would you rather integrate c++, ada,
> fortran, .net, java and cobol in obj-c so we can avoid duplicating what
> some super project in these language have done?

Heh, funny you should mention this. This type of thing is done in commercial applications more often than you might think. I can think of a few examples in my professional career where, yes, it was necessary to integrate with a well tested, well known, library that just happened to be written in another language. :)

> If html is so easy to do wrong and so hard to handle then we put a
> bullet in the s*****'s head and move on.

It's not that easy... it's nice to say that we will make a parser that will only handle "correct" HTML, but when you consider that this will make the browser virtually useless for navigating almost half of the web pages out there, the idea looses it's appeal. If you write a from scratch implementation you will need to handle such pages, if you want anyone to actually use it.

Later, GJC

[Rogelio Serrano]

On 3/4/07, Gregory John Casamento <greg_ca...@yahoo.com> wrote:
> Rogelio,
>
> > I dont think this is enough reason to invent a new ugly language. So we
> > can render broken pages properly. For apple maybe.
>
> Invent a new ugly language??? Heh. No one is doing anything of the sort. ObjC++ has been around for a while.
>

its not for me then. i think i will leave it to others to create a
gnustep browser i can use in the near future.

> > Duplication cannot be avoided. Would you rather integrate c++, ada,
> > fortran, .net, java and cobol in obj-c so we can avoid duplicating what
> > some super project in these language have done?
>
> Heh, funny you should mention this. This type of thing is done in commercial applications more often than you might think. I can think of a few examples in my professional career where, yes, it was necessary to integrate with a well tested, well known, library that just happened to be written in another language. :)
>

of course. i was talking of the extreme case. i thought integration of
khtml into cocoa was the primary motivation for inventing obj-c++.

> > If html is so easy to do wrong and so hard to handle then we put a
> > bullet in the s*****'s head and move on.
>
> It's not that easy... it's nice to say that we will make a parser that will only handle "correct" HTML, but when you consider that this will make the browser virtually useless for navigating almost half of the web pages out there, the idea looses it's appeal. If you write a from scratch implementation you will need to handle such pages, if you want anyone to actually use it.
>

we still have uses for an xhtml only application right?

> Later, GJC

>
>
>
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>

[Richard Frith-Macdonald]

I've long thought that a CoreFoundation clone done by wrapping base
would be a good idea for GNUstep/Apple portability/compatibility,
though in some case Apple add stuff to CoreFoundation that they don't
put in Foundation, so the teo probably need to be quite tightly
coupled (and perhaps inter-related).
Would you be willing to assign copyright to the FSF and continue this
work as a subproject of the base library or a separate dependent
project in the GNUstep svn repository?

[Richard Frith-Macdonald]

I think that would be good ... not because I'm saying that this
*should* be the approach taken, but because I think there is room for
more than one approach. In my estimation a port of WebKit is likely
to yield a 'complete' (ie usable across a very wide range of web
pages) solution more quickly, but the re-implementation approach will
probably produce something which can be used for viewing
documentation and other automatically generated (relatively bug-free)
pages quickly.

I guess the re-implementation approach won't meet the conditions of
the bounty, but on the other hand it's probably a lot more fun to code.

Anyway, while I'm very much against duplication of effort generally,
that doesn't mean that we shouldn't try two approaches in parallel if
people are interested in doing both. Free software is largely about
people have fun doing what they want to do.

[h...@computer.org]

On 4 Mrz., 09:08, Richard Frith-Macdonald

<rich...@tiptree.demon.co.uk> wrote:
> On 3 Mar 2007, at 22:58, Riccardo wrote:
>
>
>
> > Hi,
>
> > On Friday, March 2, 2007, at 09:29 PM, h...@computer.org wrote:
>
> >> I think it is worth to mention SimpleWebKit here - a rough
> >> implementation of
> >> WebView, WebFrame, WebFrameView, WebDataSource etc. - completely
> >> written
> >> in Objective-C without any C++. The reason is that it must cross-
> >> compile
> >> on gcc 2.95.3 for some ARM processors.

Again, that was the motivation to start a new implementation and
forget about
porting full WebKit although it is much more powerful, better tested,
more complete, etc...

>
> > I think it is a pretty good idea. If done well it should end up in
> > a cleaner implementation than apple's and also more manageable. Of
> > course it will never reach the completeness of WebKit, since even

Why never? It is just a matter of effort and how future develops.

Currently it includes:
* HTML raw parsing
* DOM Tree
* WebView, WebFrame etc.
* URL Loading

Missing is:
* Converting DOM into a View hierarchy (i.e. really showing
content...)
* CSS
* JavaScript

> > WebKit pales compared to Gecko. But it could end up being more
> > portable, more efficient and what is good even a good option since
> > you say ti is a reimplementation. As I read it, one browser could
> > use one or the other without big effort.

The target is without *any* effort - just change which framework to
link to.

> > It could be used in a light-browser as well as in applications were
> > an embedded HTML/XHTML engine is needed.

Every place where you use a WebView. For whichever purpose.

BTW: AttributedStrings can be initialized from a HTML file. This asks
a dynamically loaded WebView to do the dirty work and then extracts
the strings from the DOM. This is easily implemented in Obj-C.

> > Of course it should en handling real-world pages decently, but
> > before worrying of that (links does it and even dillo improved a
> > little) it should display correct pages correctly. The rest is
> > added "burden" actually.
>
> > Would you consider signing FSF and making it LGPL available in
> > gnustep?

I thought that it is already LGPL since it is part of the mySTEP
project - but I have found that it is nowhere mentioned explicitly the
individual header files.

I already have an FSF assignment for "changes to GNUstep" but I have
no idea if adding a new framework is a change to GNUstep or a new
project... That is something FSF has to decide.

>
> I think that would be good ... not because I'm saying that this
> *should* be the approach taken, but because I think there is room for
> more than one approach. In my estimation a port of WebKit is likely
> to yield a 'complete' (ie usable across a very wide range of web
> pages) solution more quickly, but the re-implementation approach will
> probably produce something which can be used for viewing
> documentation and other automatically generated (relatively bug-free)
> pages quickly.
>
> I guess the re-implementation approach won't meet the conditions of
> the bounty, but on the other hand it's probably a lot more fun to code.

Exactly.

> Anyway, while I'm very much against duplication of effort generally,
> that doesn't mean that we shouldn't try two approaches in parallel if
> people are interested in doing both. Free software is largely about
> people have fun doing what they want to do.

What I did not understand was the comment of some guys in earlier
mails that they do not like reimplementation but want to port WebKit.
Then, they find that it not only needs ObjC++ but also Core
Foundation. Therfore, they invent a wrapper for Base to have the CF
API (Apple btw. does it the reversed way). So, this is no
reimplementation...

Finally there have been questions for a simple web browser skeleton -
here are some references:

The most simple browser is a single WebView in a NIB file.

http://www.quantum-step.com/download/sources/mySTEP/Test/SimpleWebKit/
- this is how I test SimpleWebKit
file:///Developer/Examples/WebKit/MiniBrowser (I think there is no
direct download)
file:///Developer/Examples/WebKit/DOMTreeView

The latter two compile and link now with SimpleWebKit but I have not
tested (since there are still a lot of changes needed to make DOM
working).

-- hns

[Gregory John Casamento]

> we still have uses for an xhtml only application right?

Of course, but if we're going to write a browser or an html viewer, we may as well write one that will work in the general case. I'm not discouraging anyone from writing their own. If you want to, then that's up to you. All I am saying is that it's wise to leverage the work of others when you can.

GJC

[Rogelio M. Serrano Jr.]

Well its a matter of getting a usable xhtml application within certain
constraints. I would like to have it as soon as possible. How long would
it take to port webkit?

[Richard Frith-Macdonald]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4 Mar 2007, at 14:08, Rogelio M. Serrano Jr. wrote:

> Gregory John Casamento wrote:
>>> we still have uses for an xhtml only application right?
>>>
>>
>> Of course, but if we're going to write a browser or an html
>> viewer, we may as well write one that will work in the general
>> case. I'm not discouraging anyone from writing their own. If you
>> want to, then that's up to you. All I am saying is that it's wise
>> to leverage the work of others when you can.
>>
>> GJC
>>
>>
>>

> Well its a mar of getting a usable xhtml application within certain
>> constraints. I would like to ttehave it as soon as possible. How

>> long would
> it take to port webkit?

From what's been said already in this thread, it sounds like this is
in the region of several days to several weeks.
Using the SimpleWebKit from QuantumStep, sounds more like a process
of hours (posibly little more than writing some gnustep make files).

So of course the question really is, what is 'a usable xhtml
application' for you?
If I needed quick html support for a specific problem in an
application of mine, I know my first resort would be to try
SimpleWebKit ... then make a decision based on how well that works:
It might do what I want ... so I'd just use it.
It might come really close ... so enhancing it to do exactly what I
needed would probably be my choice
It might be a long way from what I want ... then I'd have to spend
serious time evaluating whether to enhance it or port WebKit or try
something else.

My point is really that academic discussion on this list is fairly
fruitless beyond getting a rough idea of what the options are. After
that, you *have* to get your hands dirty with some coding/
experimentation, looking at the easiest options first, and deciding
what to do based on the knowledge you gain.

If your motivation is to get the bounty for porting WebKit, then the
decision making process is simplified ... you port WebKit (unless you
talk to Jesse and find that some other course of action is acceptable
to him). If your motivation is to get specific html functionality as
quickly as possible, then you have to work out exactly what you need
and see what the easiest solution is.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFF6truSZ/wVHjv7MIRAktfAJ9X0xcg+8prDCnii+JPJvhTLDR0BQCfSlZz
5WaGIlPOCBUbM5zVwQ66s4o=
=UyOR
-----END PGP SIGNATURE-----

[Rogelio Serrano]

On 3/4/07, Richard Frith-Macdonald <ric...@tiptree.demon.co.uk> wrote:

> > Well its a mar of getting a usable xhtml application within certain
> >> constraints. I would like to ttehave it as soon as possible. How
> >> long would
> > it take to port webkit?
>
> From what's been said already in this thread, it sounds like this is
> in the region of several days to several weeks.
> Using the SimpleWebKit from QuantumStep, sounds more like a process
> of hours (posibly little more than writing some gnustep make files).
>
> So of course the question really is, what is 'a usable xhtml
> application' for you?

Im interested in xslt, xhtml and xml-fo only. I want to be able to do
atom stuff. i dont need javascript.

[Gregory John Casamento]

> Well its a matter of getting a usable xhtml application within certain
> constraints. I would like to have it as soon as possible. How long would

> it take to port webkit?

I'm not sure. The tasks are this, as I see it:

1) Write an XHTML rendering engine from scratch or
2) Port WebKit

It seems to me that neither task is trivial, so I'm not sure which would be completed first. I would take a very wild guess that they would both take a while to accomplish in any usable fashion.

Later, GJC

[Adam Fedor]

On Mar 4, 2007, at 4:09 AM, h...@computer.org wrote:

>
> I already have an FSF assignment for "changes to GNUstep" but I have
> no idea if adding a new framework is a change to GNUstep or a new
> project... That is something FSF has to decide.
>

It really a mutual decision between you and the GNUstep maintainers.
Whatever you contribute and gets put into the GNUstep repository is
by definition a 'change to GNUstep'

[Robert Slover]

On Mar 4, 2007, at 2:12 AM, Gregory John Casamento wrote:

> Rogelio,

... [elided] ...

>> If html is so easy to do wrong and so hard to handle then we put a
>> bullet in the s*****'s head and move on.
>
> It's not that easy... it's nice to say that we will make a parser that
> will only handle "correct" HTML, but when you consider that this will
> make the browser virtually useless for navigating almost half of the
> web pages out there, the idea looses it's appeal. If you write a
> from scratch implementation you will need to handle such pages, if you
> want anyone to actually use it.
>

> Later, GJC
... [elided] ...

I do not know if this helps or not, but I'll make the suggestion
anyway. Several years ago I needed a parser for a project at work that
could help extract all of the links and URL references in a set of
related HTML documents, then let me re-write the documents. This had
two purposes -- rewriting a set of HTML pages as a multi-part related
MIME message including all images and directly related documents for
emailing, and 'retargeting' -- moving a set of related HTML pages into
an altered hierarchy simply by describing the relationships between two
hierarchies (from the one used in our application to the one used by an
arbitrary customer Intranet) and a starting point. The real monkey
wrench was that the HTML was often very sloppy, containing fragments of
HTML customers had entered themselves to customize the output, as well
as incorrect HTML produced by 3rd-party software modules (which we had
source to, but no budgeted time to fix). While the latter we could do
something about, the former we could not. My solution was to use
HTML-Tidy, a W3C project by Dave Ragget. (
http://www.w3.org/People/Raggett/tidy/ ). There was a project underway
at the time to turn Tidy into a library, but it still had a way to go
-- so, instead, one of our developers took about 3 days and turned it
into a library suitable to our purpose that worked where we needed it
to -- AIX and Solaris. He gave it an interface that was very much like
SAX, on top of which we wrote our logic to re-write pages on the fly.
The Tidy code was very clean and easy to understand C, so this was a
straightforward endeavor. We were then able to handle broken pages,
with the added advantage that pages that were externalized by the
application in this way were also "correct" HTML, regardless of
fragmentary or incorrect input. This has worked so well that we've not
had to touch it since (5 or 6 years).

There, of course, now exists the official TidyLib, which I do not know
a lot about, but it could be a useful tool in getting from the point of
having a renderer that works with correct HTML/XML to one that can
understand the bulk of the incorrect HTML that exists in the real
world.

--Robert

[Rogelio Serrano]

On 3/5/07, Robert Slover <robert....@verizon.net> wrote:

> There, of course, now exists the official TidyLib, which I do not know
> a lot about, but it could be a useful tool in getting from the point of
> having a renderer that works with correct HTML/XML to one that can
> understand the bulk of the incorrect HTML that exists in the real
> world.
>
> --Robert
>

Now that, is the way to go...

>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>

[h...@computer.org]

On 4 Mrz., 18:36, Gregory John Casamento <greg_casame...@yahoo.com>
wrote:

> > Well its a matter of getting a usable xhtml application within certain
> > constraints. I would like to have it as soon as possible. How long would
> > it take to port webkit?
>
> I'm not sure. The tasks are this, as I see it:
>
> 1) Write an XHTML rendering engine from scratch or

It appears not to be as complicated as you think when doing it in a
concise manner with Objective-C only. What you need is:

a) an XML parser (NSXMLParser does fine if it has some additions to
lazily handle more or less well formatted HTML)
b) an XML/HTML -> DOMHTML* parser - I am currently finalizing that in
SimpleWebKit (it is more or less a table for translating tags to the
DOMHTML subclasses which provide some hints how to handle nesting)
c) a translator for a DOM hierarchy to a NSView hierarchy - this
finally does the rendering, so we do not need a new rendering engine
at all - maybe some additional NSView subclasses
d) wrap everything into WebFrame, WebView - this is already done
e) base NSAttributedString -initWithHTML: on these classes

> 2) Port WebKit
>
> It seems to me that neither task is trivial, so I'm not sure which would be completed first. I would take a very wild guess that they would both take a while to accomplish in any usable fashion.

-- hns

[Rogelio M. Serrano Jr.]

h...@computer.org wrote:
> On 4 Mrz., 18:36, Gregory John Casamento <greg_casame...@yahoo.com>
> wrote:
>
>>> Well its a matter of getting a usable xhtml application within certain
>>> constraints. I would like to have it as soon as possible. How long would
>>> it take to port webkit?
>>>
>> I'm not sure. The tasks are this, as I see it:
>>
>> 1) Write an XHTML rendering engine from scratch or
>>
>
> It appears not to be as complicated as you think when doing it in a
> concise manner with Objective-C only. What you need is:
>
> a) an XML parser (NSXMLParser does fine if it has some additions to
> lazily handle more or less well formatted HTML)
>

or pass html through html tidy first.

[h...@computer.org]

> or pass html through html tidy first.

It appears unnecessary to me to go that way because it first parses
HTML into a tree, then fixes some things and writes out HTML just to
parse it again...

I have read through the rules html tidy uses and in most cases the
following rules will have the same or a quite similar result (ok it
needs more testing with badly designed pages):
* if the closing tag does not match the opening tag, search outwards
until you find one (if you don't find, ignore)
* be lazy with missing quotes in tag attributes
* convert all tag names and attribute names to upper case
* ignore <html>, <head>, <body> (except for attributes)
* some tags always go to the HEAD section (e.g. <title>, <meta>)
wherever they appear
* ignore unknown tags

As soon as I have new more or less stable code, I will upload a
snapshot and you can look into it.

-- hns

[Thom Cherryhomes]

I do want to ask, have any of you actually done any of this sort of
thing before?

It always seems, every time I run a page that's been badly formatted
through Tidy, it's a crap shoot as to whether it will wind up with the
same visual representation that was intended in the first place.

It's just that you guys are trying to create an elegant solution for
an ideal world without fully understanding the interaction of all the
pieces you guys are trying to put together. IF YOU ACTUALLY STUDY
Gecko or KHTML, you'll find that great lengths have been done to make
sure that special cases are taken care of, without disturbing the way
the stream is entered into the parser.

This isn't as simple as you guys are making it out to be, and it's all
because it was never done RIGHT to begin with.

It's not that this is impossible, but you are creating bigger
headaches farther down the road, for what? to make sure this fits into
your world view of how things should be? come on, guys. THINK.

-Thom

[Rogelio Serrano]

On 3/5/07, Thom Cherryhomes <thom.che...@gmail.com> wrote:
> I do want to ask, have any of you actually done any of this sort of
> thing before?
>
> It always seems, every time I run a page that's been badly formatted
> through Tidy, it's a crap shoot as to whether it will wind up with the
> same visual representation that was intended in the first place.
>

thats bad html so it should look bad. we are not trying to grab market
share from these guys you know.

> It's just that you guys are trying to create an elegant solution for
> an ideal world without fully understanding the interaction of all the
> pieces you guys are trying to put together. IF YOU ACTUALLY STUDY
> Gecko or KHTML, you'll find that great lengths have been done to make
> sure that special cases are taken care of, without disturbing the way
> the stream is entered into the parser.
>
> This isn't as simple as you guys are making it out to be, and it's all
> because it was never done RIGHT to begin with.
>
> It's not that this is impossible, but you are creating bigger
> headaches farther down the road, for what? to make sure this fits into
> your world view of how things should be? come on, guys. THINK.
>

i dont understand the last statement. as far as i know we are avoiding
a big headache. the web is not just about html. thats boring. REST and
xml technologies are a lot more interesting.

I have done a lot of thinking and i can only find out so much.
Somebody has to actually try and find out. i dont make big designs up
front. if thats what you mean by "thinking first" then sorry.

all i care about is xhtml, xslt and xml-fo. the rest is just a bonus.
we are developing within constraints here.

[h...@computer.org]

Good!

So, I need a volunteer who has a running GNUstep system to help
porting/adapting (since I develop on Xcode/mySTEP). And the result can
be finally added to GNUstep.

-- hns

[Rogelio Serrano]

On 5 Mar 2007 02:53:09 -0800, h...@computer.org <h...@computer.org> wrote:

> > or pass html through html tidy first.
>
> It appears unnecessary to me to go that way because it first parses
> HTML into a tree, then fixes some things and writes out HTML just to
> parse it again...
>

i thought that was a good trade off...

> I have read through the rules html tidy uses and in most cases the
> following rules will have the same or a quite similar result (ok it
> needs more testing with badly designed pages):
> * if the closing tag does not match the opening tag, search outwards
> until you find one (if you don't find, ignore)
> * be lazy with missing quotes in tag attributes
> * convert all tag names and attribute names to upper case
> * ignore <html>, <head>, <body> (except for attributes)
> * some tags always go to the HEAD section (e.g. <title>, <meta>)
> wherever they appear
> * ignore unknown tags
>
> As soon as I have new more or less stable code, I will upload a
> snapshot and you can look into it.
>
> -- hns
>

thats a good start.

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>

[Richard Frith-Macdonald]

On 4 Mar 2007, at 11:09, h...@computer.org wrote:

> I thought that it is already LGPL since it is part of the mySTEP
> project - but I have found that it is nowhere mentioned explicitly the
> individual header files.
>
> I already have an FSF assignment for "changes to GNUstep" but I have
> no idea if adding a new framework is a change to GNUstep or a new
> project... That is something FSF has to decide.

Actually I think it's mostly up to you ... if Greg, as official
maintainer is willing to accept it (I would be very surprised if he
said no), and you want to contribute it, then I'm pretty certain that
all you need to do is announce that you want to contribute it as
part of GNUstep, change the headers to say that it is part of
gnustep and the copyright is owned by the FSF, and your existing
assignment will cover it. There is no special paperwork or legal
procedure to be done to make something part of GNUstep.

> What I did not understand was the comment of some guys in earlier
> mails that they do not like reimplementation but want to port WebKit.
> Then, they find that it not only needs ObjC++ but also Core
> Foundation. Therfore, they invent a wrapper for Base to have the CF
> API (Apple btw. does it the reversed way). So, this is no
> reimplementation...

I think Chris was doing the CoreFoundation stuff anyway ... nothing
to do with the current 'WebKit Bounty' discussion directly but an
interesting point to raise (in the context of porting webkit) that a
CoreFoundation clone is already under development.

It's also good to remember when a bunch of people on the discussion
list disagree with something, that all they are doing is giving their
opinions. Nothing that's said prevents people from getting on and
doing what they want to do and contributing what they want.

To take that a step further ... even if some people are really
hostile to an idea on the discussion list, that doesn't usually
reflect the attitude of the project as a whole or that of the core
developers, and it's highly likely that other people would welcome
contributions that a small minority have loudly complained about.
It's also easy to massively over-estimate the amount of opposition
that the author of an email meant to communicate.

So, it would be a mistake to be put off by negative sounding
comments. Rather, you should assess them, take technical ideas from
them where appropriate, and make up your own mind.

With GNUstep core we have a focus on implementing core libraries for
MacOS-X compatibility, but even where ideas do not fit with this, we
have plenty of options of adding projects alongside the core, with
space in svn repositories for both gnu and non-gnu projects and with
associated Etoile and Backbone projects for more desktop oriented code.

[Jesse Ross]

> To take that a step further ... even if some people are really
> hostile to an idea on the discussion list, that doesn't usually
> reflect the attitude of the project as a whole or that of the core
> developers, and it's highly likely that other people would welcome
> contributions that a small minority have loudly complained about.
> It's also easy to massively over-estimate the amount of opposition
> that the author of an email meant to communicate.
>
> So, it would be a mistake to be put off by negative sounding
> comments. Rather, you should assess them, take technical ideas
> from them where appropriate, and make up your own mind.

This is a great point. I originally posted the bounty for WebKit
because, as a web developer, that really _is_ what I would like to
see, and what I am willing to put money towards. However,
SimpleWebKit and some of the other solutions that have been brought
up (like using HTML Tidy), don't seem like bad ideas in the slightest
-- in fact, they may very well turn out to be great solutions that
get us further than a port would. So, while the bounty doesn't apply
to them, that doesn't mean that those options shouldn't be explored,
if they scratch someone's itch by covering the use-cases that their
app requires.

J.

[Lars Sonchocky-Helldorf]

Am 03.03.2007 um 21:25 schrieb Gregory John Casamento:

> Micheal,

>
> I completely agree, It would be foolish not to leverage all of the
> work by the KHTML and WebKit teams. GNUstep doesn't need to
> maintain it's own HTML rendering engine. It's too big and time
> consuming and we have more important things to focus on.

1+

>
> Later, GJC
> --
> Gregory Casamento

Lars

[Lars Sonchocky-Helldorf]

Am 04.03.2007 um 08:12 schrieb Gregory John Casamento:

> Rogelio,
>
>> I dont think this is enough reason to invent a new ugly language.
>> So we
>> can render broken pages properly. For apple maybe.
>
> Invent a new ugly language??? Heh. No one is doing anything of
> the sort. ObjC++ has been around for a while.
>

>> Duplication cannot be avoided. Would you rather integrate c++, ada,
>> fortran, .net, java and cobol in obj-c so we can avoid duplicating
>> what
>> some super project in these language have done?
>
> Heh, funny you should mention this. This type of thing is done in
> commercial applications more often than you might think. I can
> think of a few examples in my professional career where, yes, it
> was necessary to integrate with a well tested, well known, library
> that just happened to be written in another language. :)
>

>> If html is so easy to do wrong and so hard to handle then we put a
>> bullet in the s*****'s head and move on.
>
> It's not that easy... it's nice to say that we will make a parser
> that will only handle "correct" HTML, but when you consider that
> this will make the browser virtually useless for navigating almost
> half of the web pages out there, the idea looses it's appeal. If
> you write a from scratch implementation you will need to handle
> such pages, if you want anyone to actually use it.

To mention it one more time: If we really want and need to go pure
ObjC for this we should ask http://www.omnigroup.com/ if they hand us
their OmniWeb 4.2 implementation with a reasonable licence (and for a
reasonable price if they insist on this). This stuff is not up to the
latest in web rendering but it would save us a lot of time if used as
a starting point.

>
> Later, GJC

regards, Lars

[Chris B. Vetter]

On 3/4/07, Richard Frith-Macdonald <postm...@tiptree.demon.co.uk> wrote:
[...]

> I think Chris was doing the CoreFoundation stuff anyway ... nothing
> to do with the current 'WebKit Bounty' discussion directly but an
> interesting point to raise (in the context of porting webkit) that a
> CoreFoundation clone is already under development.

[...]

I've got a pre-34x.yz version working.

The problem is with Apple's APSL. I don't really know how it relates
to LGPL and I don't know how Apple Legal would react if a
GNUstep'ified version of the current CF-368.27 pops up since you have
to register for an Apple ID in order to download the source.

But I guess making a patch-file available would be OK.

--
Chris

[Graham J Lee]

On 6 Mar 2007, at 08:52, Chris B. Vetter wrote:

> [CF-Lite]

> The problem is with Apple's APSL. I don't really know how it relates
> to LGPL and I don't know how Apple Legal would react if a

http://www.gnu.org/philosophy/apsl.html

Cheers,
Graham.