[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: SoC mentor for khtml
From:       Maksim Orlovich <maksim () kde ! org>
Date:       2006-04-28 14:17:29
Message-ID: 200604281414.k3SEEHsu018917 () ms-smtp-04 ! nyroc ! rr ! com
[Download RAW message or body]

LiuCougar wrote:

> Hi,
> I'd like to apply for a khtml related project for SoC 2006.
> 
> It seems to me that no one is currently listed as mentors for khtml
> related stuffs in
>
http://wiki.kde.org/tiki-index.php?page=KDE%20Google%20SoC%202006%20ideas#id403846
> 
> anyone interested in mentoring?

Hi... I am interested in mentoring some of these items (in particular the
one you asked about below, and the JS one, which are basically 2 things
that I added)

> 
> In addition, the ideas about khtml are too brief to anticipate the
> workload.
> 
> The "Rewrite DOM 2 traversal code" item, does it refer to
> Document Object Model (DOM) Level 2 Traversal and Range Specification
> (http://www.w3.org/TR/DOM-Level-2-Traversal-Range/)
> or only
> Document Object Model Traversal
> (http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html)

It's referring to traversal only. The problem, basically, is that we have
code for it, but it's super-buggy, and super-crashy, and isn't even close
to handling all the tricky cases. 

(This should illustrate:
http://lists.kde.org/?l=kde-commits&m=113128670714572&w=2)

I am not really sure of the extant to which our range stuff works, to be
honest, but I haven't seen any crashes reported due to it, either.

> 
> I searched in http://www.khtml.info/ and google for information about
> current status for DOM 2 traversal, with no much outcome .
> 
> According to
>
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28DOM%29#Traversal
> only one render engine (Presto) implements all Traversal interface, while
> gecko finishes about half.

Well, it's definitely true that this may not be the most important thing to
support. The suggestion is there because it's basically a nice
mostly-standalone type of project, so I think it could help someone
interested in KHTML hacking get involved... Well, that, and the fact that
the current implementation is just plain bad.

> 
> Another query is whether the intended target is  kde 4 or kde 3? (I
> hope it's the former)

It depends. For many things it really doesn't matter that much, modulo
changing data structures when porting. The traversal stuff will likely 
need binary incompatible changes, so it has to be 4...

> 
> thanks,
> Cougar


Thanks for interest in this,
Maks


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]