'Re: Open Issues'

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

List:       kde-kafka
Subject:    Re: Open Issues
From:       Stephan Heigl <stephan () eisscholle ! de>
Date:       2000-10-26 19:59:35
[Download RAW message or body]

On Thursday 26 October 2000 20:22, 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.
>
> 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 like this idea very much. But as far as i know this will still require some 
changes in khtml, right?

> > 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.
>
> - --
> Thomas Zander                                           
> zander@earthling.net The only thing worse than failure is the fear of
> trying something new -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.2 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE5+HZ+Nj0pheMOlEoRAnkQAJ9W0SIX6B8+GCdtcT7UFfFilLTEFwCfSKv0
> CtmiFzQV//mtmQIdYeDzaOY=
> =z5xv
> -----END PGP SIGNATURE-----
> _______________________________________________
> Kde-kafka mailing list
> Kde-kafka@master.kde.org
> http://master.kde.org/mailman/listinfo/kde-kafka

-- 

regards,

stephan

___________________________________________________
Website: www.eisscholle.de 
ICQ: 12707332 
Jabber: stephan@jabber.com
_______________________________________________
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] 