Fwd: khtml wishlist

[Nicolas Deschildre]

On Saturday 22 March 2003 14:07, Peter Kelly wrote:
> 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.

hi Peter,
I'm happy that someone in the khtml side also want to work for the same 
project! It's right that since a few years khtml has been very much improved 
and what was impossible three years ago is now _almost_ easy to do :)
There are still some minor issues, but i'm confident this time kafka will 
succed.

>
> 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)?

Just in the quanta integration side, it will allow to add some informations 
(e.g. pointer to the quanta internal nodes) and, more important, imagine that 
a small icon (an image Node) represent a comment : you click on it and a 
dialog popups and allows editing the comment : to differentiate real image 
nodes and thses nodes, we'll need to add some properties to the nodes.

Having said that, i realize that it could be handled in the quanta nodes side, 
but it would be more difficult... i'll consider this solution.

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

I'll ckeck it 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.

Yes, it would be fine :)

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