[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:       Paulo Moura Guedes <moura () kdewebdev ! org>
Date:       2005-06-07 2:25:10
Message-ID: 200506070325.10622.moura () kdewebdev ! org
[Download RAW message or body]

On Tuesday 07 June 2005 02:56, Jens Herden wrote:
> > > Structure tree.
> >
> > I don't know if it would be bad. It would give a stronger indication to
> > the user to what he should fix.
>
> I know, this is very bad :-)
> If you have a error at the very beginning of the document the tree will be
> almost empty and useless. So I have to fix the errors top down to get a
> usefull tree? What a horror! Think about a document someone else created, I
> have to suffer because the other author did it wrong and I have to fix
> his/her error to get the structure tree?
> I hate it if a tool force me to work in a specific way and try to educate
> me to do it right. Where right means what the deleloper of the tool mean is
> right and not what I, as a user, think is right.
> To make it very clear here. This would be a radical change in Quanta's
> philosophy and if Quanta would choose to go this way I most likely will
> think about another tool that fits more to what I think is the right
> approach. I do not want to threat here if Quanta wants to go this way I am
> fine with it.

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.

> > We should also ask ourselves what use is given
> > for the structure tree.
> > BTW, do you think it's importante for the node tree to show non XML
> > nodes? I can't see no use for that.
>
> I do see a use, but it is more theory than practical experience. You should
> ask people who are working a lot with PHP to get a better picture.

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

> > > And VPL should also display a broken page.
> >
> > It already does, because it's rendered by KHTML.
>
> So are we talking about the future or about what we have now? We came to
> the point where we agreed about having only _one_ tree is the way to go.
> Where is KHTML then?

I don't understand the question. Are you suggesting we should change our 
rendering engine?

> > > > > The parsing of special areas is already separated from the
> > > > > HTML/XML.
> > > >
> > > > But it's all going to the same tree and it's done in a more or less
> > > > syncronized way IIUC.
> > >
> > > Yes and what is wrong with this?
> >
> > It would be interesting and a lot easier if we completely separate the
> > parsing of special areas from the parsing of HTML, don't you think? I
> > would like to know if special area nodes need to belong with the XML node
> > tree. My idea is to reuse some XML parser (and make it tolerable to
> > errors if possible) and have the script functionality as a different
> > module.
>
> For me it is only partly about how intersting or easy stuff is. The more
> important question is what the users expect and want. And I do not see that
> we should careless drop features we have because it is easier or more
> interesting. Quanta must go a step foreward not backwards.

I'm not talking about features but an approach on how to implement things.

> Of course the internal coding is independent and here it is about what is
> easier or more interesting. 

Yes.

> So I agree that reusing an existing parser can 
> be a good choice and it is also smart to untie XML and script parsing. But
> detecting the script areas when you are parsing XML is also smart because
> it prevents another parsing just for area detection.

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.

> > > What do you mean by syncronized? You could
> > > read in Andras mail that the special areas are skipped first and parsed
> > > later.
> >
> > I was not very accurate but they are mixed in Parser::parse(). There is a
> > first pass for detecting special areas along with the XML stuff.
>
> Yes and how do you see a way to change this without loosing information
> about the special areas?

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

> > P.S.: IRC? ;)
>
> Better not yet, this is very important and should be available for others.

I though that we might accelerate our ideas and then could expose them to the 
list.

-- 
Paulo Moura Guedes

http://caixamagica.org
http://kdewebdev.org
_______________________________________________
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]