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

List:       kfm-devel
Subject:    Re: designmode in khtml
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2003-07-08 16:33:41
[Download RAW message or body]

Am Dienstag, 8. Juli 2003 14:09 schrieben Sie:
> On Mon, 2003-07-07 at 13:29, Leo Savernik wrote:
> > Hello,
> > 
> > In the holidays to come I'd like to implement designmode[1] for khtml.
> > However, I have some questions to be clarified:
> > 
> > Is anybody working on this already? (e. g. Apple/Safari?)
> > If yes, I won't even start as not to inflict useless duplication of work.
> > (I know about kafka, this is not a duplication, designmode would in fact
> > take a burden off of the kafka developers.)
> 
> Hi!
> (First, sorry for my not-perfect english.)
(No need to be sorry, I'm not perfect either ;-) )
> So finally, you'll do it! I was afraid it was only words, and that
> nothing will come from these words...as sometimes it happens.

You don't know me. I nearly never boast with features without actually taking 
the plunge myself.

> You know, it is more than taking a burden off of me, because i am
> lacking of time, i never write a single line of code for khtml and i do
> not know at all the internal structure of it!
> If you need help, you can tell me, but i'd like to finish first some
> kafka stuff and i hope to be ready to help you on august the 10th (i'm
> away, with maybe no internet connection from july 20th to august 10th).
> 
I won't start now (as I already told in bug 48302) but in late July after my 
final exam. As I have to merge loads of Safari stuff (which I never did 
before) I'm not sure how far I get by august 10th, but I hope to finish basic 
cursor navigation as early as possible, which is not only needed for 
designMode, but also for better UAAG compliance[2] (currently, one cannot 
even select text within khtml using the keyboard only).

> I'd like also to agree with an API which works for DesignMode and for
> kafka and its future features.
> First, how do you want to define the cursor position? DOM::Node + the
> position inside this DOM::Node (getCursorPos(DOM::Node &node, uint
> &pos))is fine with me. And let's say that when a Node is selected(e.g.
> an IMG), the cursor pos is -1. A function to set the cursor would also
> be needed.
> 
For img I intend to have two offsets, 0 means left of img, 1 means right of 
img. I think the cursor position should never be invalid because even when a 
selection is active we need to know which side the selection (on the 
beginning or on the end) is going to be extended on.
For setting the cursor position I think I'll leverage the implementation of 
the mouse selection into some public API, but I can't make sane assumptions 
now.

> Also some callbacks functions whenever a DOM::Node has been created, has
> been modified or is about to be deleted. Note that for creation and
> deletion, it might be two possibilities : node created/deleted and node
> and childs created/deleted. Also one callback when the cursor position
> has changed.
> 
I think the DOM Mutation Events[1] are best suited for this purpose. And as 
far as I see they are implemented in khtml, thanks to pmk :-)
I only hope that they don't cause performance bottlenecks.

> Finally, according to the designMode specs, you only had to put one
> designMode=on on a Node so that all the childs DOM::Node can be edited.

You can only set designMode on the document object, not on single nodes. 
That's what contenteditable is made for. designMode takes effect for the 
whole page.

> It should be better (for the kafka side) that all the DOM::Node have two
> flags:
> * canBeDeleted. If set to true, in case of text, it implies that the
> text can be edited and deleted, and can have the cursor Focus. In case
> of others "graphical" Nodes such as IMG, TABLE, OBJECT, etc..., you can
> delete it by pressing backspace or delete when the cursor is near this
> Node. If set to false, you can't modify/delete the text and delete
> "graphical" Nodes.
Any node should be deletable in an editor, or did I oversee a special aspect 
here?

> * canBeModified. Useful only for the "graphical" Nodes. It implies that
> when we click on these Nodes, they get the focus, and little squares are
> drawn all around to be able to change the size. If set to false, you
> can't modify "graphical" Nodes.
> I was thinking of a last one, canHaveCursorFocus, but it might be
> redondant with canBeDeleted as when we can delete a Node, we must have
> the cursor to delete it, and when we have the cursor, it would be weird
> not being able to delete the Node. But let's put it, it might be usefull
> sooner of later.
> 
I'm not sure if any of these are needed at all. If basic cursor navigation and 
selection works, both of us will have a much better position to define a 
useful API.

> I hope i don't ask you too much!
> Finally, thanks very much again, i'd like to help you as soon as
> possible!
> 
> ++
> Nicolas

I hope you don't mind that I sent a copy to kfm-devel, too.

mfg
	Leo

[1] 
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-mutationevents
 [2] http://www.w3.org/TR/UAAG10/guidelines.html#tech-device-independent-ui


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