Kafkapart problems with CVS HEAD

[Adam Treat]

--- Nicolas Deschildre <nicolasdchd at ifrance.com> wrote:
> You too?? :-) I guess it's the getCursorPosition which give weird position, 
> no? I've submitted this to Peter which work on khtml, and i'll make a bug 
> report soon.

No, I don't think it is the cursor position.  It is a problem with the internal logic of the
selection mechanism in KHTML itself.  Seems to be borked in more than a few ways.  Have a look at
the bug i listed in the last post. http://bugs.kde.org/show_bug.cgi?id=54395

> No, just on small bunchs of text! It flickers on large blocks of text as well 
> as on little blocks on italic, bold ,... text. What i don't understand is 
> what is flickers : flickering needs two updates : one for the white screen 
> and one for the text coming back, but i use updateContents() one time... I 
> didn't look for the solution at the moment, but maybe one easy solution 
> exists (remove updateContents()) else i've also submitted that to peter.

For sure the flicker exists on all the updates, but continuously doing a backspace on a large
block of text really exposes the problem to the eye ;)

> It might or might no be a solution. I think the easiest way would be to fix 
> that inside khtml, which would avoid the need of custom-redrawing the text 
> which will be tricky (need the good text size, the good color, need the 
> bounds of the text (quite impossible to get that, the DOM::Node::getRect() 
> function only offers basic bounds which couldn't be used for non-rectangular 
> objects)) But maybe i didn't understand what you were meaning.. tell me!

Ok, so like you said we don't necessarily have to have this for text editing, but it might be
useful and we'll definitely need custom drawing for things like tables and layers, no??  To get an
idea of what I was talking about open up KPresenter and add some text to a slide ... You'll notice
that the text is encapsulated in a text edit box that you need to "enter" in order to change the
text.  I was thinking of something similar for Kafka that way we don't have to update the node and
redraw when the user is continuously editing a block of text.  After the user "leaves" the edit
box we'd update the DOM tree and let KHTML redraw the text perhaps with a dotted line around the
block.  Does this make sense?  It would provide a solution for all the flicker we'll run into and
perhaps we won't have to derive from a node to do it.  I don't know where the hook would be, but
we'd need to override some paint routines in a really low level of KHTML to get after what I'm
talking about.  Perhaps, KHTML would need to be modified to expose some low level paint method
that currently is hidden.  If you think this is worthwhile then perhaps Peter or whomever can
cross post to the kfm list.  I'm on the list now and lurking ;)
 
> > This way the user could exit the edit box and
> > update the entire DOM at once with the new text instead of continuously
> > updating and redrawing.  We'll have to custom draw other elements anyways
> 
> We haven't discussed of that issue yet, but let me explain how i see things : 
> i suppose that you talk about drawing the stuff like little icons that will 
> represents the <!-- -->comments for example. I was thinking of using normal 
> Image nodes which will be derivated to contains the extra info needed for the 
> comment node (like the comment itself), and theses images nodes will 
> represent the comment : it will avoid the need to know exactly where to 
> custom draw our comment and updating its position when updating the DOM tree. 
> Oh i realized that you maybe don't know that it's impossible to derivate the 
> DOM::Node and thus their paint() method that's why i didn't consider use 
> theses nodes and derivate the paint() method.
> You will tell me that i've said that i want to derivate the Image nodes to 
> contains some others infos, but i use a little trick : instead of derivating 
> the node, i will add these info on the corresponding quanta node.
> Having said that, i recognize that it will be easier to derivate DOM::Node but 
> peter said that it would be quite difficult as the DOM::Node are only the 
> interface to the NodeImpl... I'll ask him if it is not really possible.

That is certainly one way of going about it and it is a cute trick in the case of comment nodes,
but I imagine we'll have need of more complex drawing for other node types.  Once again, tables
come to mind...  JavaScript tags and all so on.  We potentially have a number of structures to
paint on top of the KHTML canvas for various nodes and it might be cleaner to ask for these hooks
now instead of pushing and popping new nodes into the tree...  I really think we should get some
of the KHTML developers to give us the scoop here and they'd probably be invaluable in these
fundamental design thingies up front.  On second thought I'm going to go ahead and CC this to the
kfm list ;)

> ++
> Nicolas


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com