'Re: Open Issues'

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

List:       kde-kafka
Subject:    Re: Open Issues
From:       Jonathan Bacon <f9808590 () wlv ! ac ! uk>
Date:       2000-10-26 19:15:55
[Download RAW message or body]

On Thu, 26 Oct 2000 20:22:54 +0200 Thomas Zander <zander@xs4all.nl> 
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:
> 
> <html>
>   <?echo $text; ?>
> </html>
> 
> in normal khtml this would create 
>  [html]
>      [texttag] <?echo $bgcolor; ?>"
> 
> 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

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