On Thu, 26 Oct 2000 20:22:54 +0200 Thomas Zander wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 25 October 2000 22:33, Stefan Schimanski wrote: > > Hi, > > I will write down here several issues I see at the moment. I only speak > > about the core html editor, not the gui around it. > > I can't find anything missing. I think I have a small amount of answers. I > simply don't know if they are viable. > > > A) loading a html page into the editor, changing it, writing it back into > > html must to be absolutely lossless. > > I have written a design document for kafka a couple of months back, it seems > that I was quite ignorant about the khtml development. But in light of the > fact that khtml is open to additions I want to suggest the possebility to add > some of the ideas I had back then to the khtml code. don't worry, we are all ignorant to things we don't know. :-) Good idea about adding code to KHTML and providing WYSIWYG web editing functionality, but would Lars allow it? > Please read kdenonbeta/kafka/handbook/design.txt. The bad "source-code" > chapter is very interresting IMO. > > Something we could then do is to add code to the tokenizer to accept > "plugin-tokens". In normal html viewing there would be no plugins registered, > in kafka however tokens like "whitespace", "php-tag" etc, could be added. > Which would be then be stored in the dom-tree. > Example: > > > > > > in normal khtml this would create > [html] > [texttag] " > > But after registering the php and whitespace objects we would have > [html] > [kafka-whitespace] " " > [kafka-php tag] "echo $bgcolor;" > [whitespace] "\n" > > Implementation specific, all kafka objects would have to subclass a > "unknown-token" in the khtml lib, some smart code would have to sneak into > the tokenizer to parse the "plugin" tokens. I see what you mean, but how would you know what is a PHP, JavaScript, ASP tag etc. Also, what happens if another program wishes to manipulate tags at the tokenizer leve. we could say that if the tokenizer sees a PHP tag it is represented as a Kafka tag, but what happens if say Quanta would like to use it? Also, how can these tokenized tags update the DOM tree so we can represent them usefully? I admit I am stupid whn it comes to how KHTML works, so you may need to correct me on some points. :-P > > B) editing must be interactive and intiutive. This means that drag'n'drop, > > wysiwyg editing of positions and dimension (i.e. of images, tables, divs) > > is possible. > > Certainly, but is this not really easy if you have a DOM? You can ask khtml > where stuff is, so finding out which token has been clicked is really easy. > All we have to do is write logic that wil do the drawing. Would this mean updating the rendering of the KHTML widget? Also, do you think it would be a good idea that all elements rendered in the Kafka KHTML widget have coordinates associated with them in the DOM so when a user clicks on the page, the coordinate is logged and checked in the DOM so we know which element to edit? Jono -------------------------------------- Jono Bacon - [vmlinuz] -- jono@kde.org KDE/Qt Developer - Founder of Linux UK -------------------------------------- _______________________________________________ Kde-kafka mailing list Kde-kafka@master.kde.org http://master.kde.org/mailman/listinfo/kde-kafka