[quanta-devel] Kafkapart problems with CVS HEAD

[Eric Laffoon]

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

On Monday 24 March 2003 11:07 am, Adam Treat wrote:
> --- 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 ;)

First off the method you described is not really what people will be expecting 
and I hope too early to be discussing as a way of making things work. There 
will be real problems with long text entry, text emphasis (unless you super 
impose a rich text widget) and more. I don't think this would be well 
received and I'd only want to do it if there were no other solution, which I 
hope we don't come to.

Second, as long as Peter has offered to be Liason on our list I'm not sure we 
should be dumping a bunch of mail on kfm-devel as we can generate a lot with 
this.  
>
> > > 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 ;)

Before we charge too far ahead on this let's run it through our list. Are you 
familiar with Quanta's parse tree? We already have these nodes and more as we 
are well beyond just DOM. So while we need to index to the DOM nodes my 
undestanding was that we could super impose between the Kafka part and 
Quanta's parse tree. Again, I haven't gotten into the Kafka code so this is a 
"black box" overview based on previous discussions of which programs assumed 
vairous responsibilities.
>
> > ++
> > Nicolas
>
Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+f132SiV5TqRTAEsRAk9BAJ9cWqNRe8YIHLy8eTtGIZ8U7i3VuACeKIfz
4KSTh9Urxy4NRupjixrFGdo=
=Gbfj
-----END PGP SIGNATURE-----