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

List:       quanta-devel
Subject:    Re: [quanta-devel] Re: Using KDOM in Quanta
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-06-08 13:17:45
Message-ID: 200506081617.46212.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 07 June 2005 05:25, Paulo Moura Guedes wrote:
> Ok. My idea was that an empty structure tree would not prevent you
> from editing the document, but I guess you are right as the tree
> might be important for some users.

Empty struct tree means empty node tree, means Quanta becomes Kate. ;-)

The struct tree is useful for me (as Quanta coder) and users (XML 
writers) as well and is quite appreciated! 

> This is an important issue as it could determine if special areas
> must belong with the rest of the tree.

Well, hiding them from the struct tree is possible and might even makes 
sense. But this doesn't mean that we get rid of them from the node 
tree. The struct tree is a visual representation of the node tree, 
where we can control (and already do) which nodes appear and which 
don't.

> But you don't parse the script areas in detail twice so I doubt it
> would turn out to be a performance bottleneck. We could also have a
> lazy approach for parsing XML. IMHO this performance issues are
> premature and we should focus on choosing the right way of doing
> things.

I'm not sure what you mean, but detailed parsing of script areas is done 
only once.

> The idea was to separate the waters as discussed above, but I'm not
> sure if I understood correctly.

As I said: we need to find the end of the special areas. How would you 
do that without a quick parsing of that area?

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


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