Fwd: khtml wishlist

[Peter Kelly]

On Sun, 23 Mar 2003, Andras Mantia wrote:

> Hi,
> 
>   As you may heard the rumours and saw the latest KDE CVS Digest, we have 
> plans to add WYSIWYG capabilities to Quanta. This is done by creating a KHTML 
> derived part. The code base is the old Kafka from kdenonbeta. Currently it's 
> main developer is Nicolas Deschildre and Adam Treat will also jump in. I made 
> this introduction and would like to forward the first "list" about what 
> Nicolas thinks we would need from the KHTML part. I hope you can collaborate 
> and will be productive. ;-) I think the best mailing list where things can be 
> discussed is kfm-devel, so Nicolas should subscribe there, but correct me, if 
> I'm wrong. 
> 
> Andras

Well, this is interesting to hear :)

This is almost exactly what I was trying to do almost three years ago and 
how I got involved with KHTML development. I never ended up going back to 
Kafka because there were too many things to fix in KHTML and got caught up 
with that instead. But it's good to see someone is finally doing this. I 
hope it works out this time (I've seen a number of aborted attempts revive 
Kafka), so I'll be happy to answer any questions you have.

I strongly recommend familiarising yourself with the KHTML codebase (not 
necessarily all of it - mainly the DOM implementation and KHTMLPart), as 
it's likely you'll run into issues where things don't work quite how you 
expected and you may need to improve or tweak some aspects of it. But it
now has far better support for dynamic document modification and I think 
you'll find most of what you need to do is already possible, with the 
exception of some extra hooks you may need added into access additional 
internal information.

> 
> ----------  Forwarded Message  ----------
> 
> Subject: [quanta-devel] khtml wishlist
> Date: Saturday 22 March 2003 01:14
> From: Nicolas Deschildre <nicolasdchd at ifrance.com>
> To: quanta-devel at mail.kde.org
> 
> hi everyone!
> Here's the wishlist i wil submit to the khtml guys, feel free to add some
> needed features :)
> 
> Very important:
> - Being able to create nodes which derivates from the existing nodes
> (impossible for the moment as creating a DOM::Node isn't sufficient!) maybe
> by providing a special Node constructor which takes care of all the node
> internals (creating the NodeImpl,...)

All of the node types supported by KHTML are done in Impl classes, which 
are not in the public API. The reason for this is so that we can change 
the Impl classes without breaking source or binary compatibility. So 
there's no way currently to extend these nodes.

Why do you want to do this? Can what you are trying to do be achieved 
using the existing node types (e.g. Element)?

Having said that, I believe ksvg has done something along these lines in 
terms of having it's own node types. I must admit I haven't really had a 
look at how they've done this, but it may be worth checking out.

> - Having a write access to the root Node of the DOM Tree.

This should already be the case.

> 
> Important, but not urgent:
> - Being able to access the CSS stylesheet and to modify them

This is already possible - many sites do this using javascript. However 
for efficiency the rendering display is not updated immediately when the 
calls are made (as this also the case with DOM tree manipulation). Instead 
this is done by DocumentImpl::updateRendering(), which is called after 
script execution completes. However, there's no public API for this; we 
can possibly look at adding one.

> - DOM::Node::getCursor() should stay, be improved (still some minor bugs e.g.
> the cursor position is the same for two differents offset near a whitespace,
> and sometimes the cursor position at offset 0 give the coordinates of the end
> of the line) and implemented for Element (e.g. Images, tables,...)
> - The event informations should be public and more precise (e.g. for the
> moment clicking on a Node gives the parent Node :-)
> 
> And finally the least important :
> - remove flickering when updating nodes
> - DOM::Node::getRect() should stay
> 
> Any comments (adam?)?
> I realized that without the two first items, i won't be able to start the
> kafka integration!
> ++
> Nicolas
> _______________________________________________
> quanta-devel mailing list
> quanta-devel at mail.kde.org
> http://mail.kde.org/mailman/listinfo/quanta-devel
> 
> -------------------------------------------------------
> 
> 

-- 
Peter Kelly
pmk at kde.org