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

List:       quanta-devel
Subject:    Re: [quanta-devel] parser in Quanta
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2006-01-18 4:01:08
Message-ID: 200601181101.14873.jens () kdewebdev ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Andras,

> > I wanted you to look into this to get an idea what kind of parser I
> > want to have and I knew that we can not use QXmlReader. But the whole
> > structure around QXmlReader with reader and builder is worth to copy,
> > I think.
>
> Might make sense. But I think the accent is on copy. Or maybe can be
> used as a source of inspiration.

Actually my wording is not precise. What I really meant was to use a 
QXmlReader derived class to have the possibility to plug it into the KDOM 
builder. 


> > So my suggestion was, like you said, to create our own
> > QXmlReader derived class which is very error tolerant and fixes as
> > many problems as possible to get a useable KDOM tree for the
> > renderer.
>
> Still I'm not sure what we can get from it and if it is possible to
> integrate with KDOM in the way they intended or we just have to use
> hack after hack.

We are in the process of evaluation. How can we find out more about this?


> > Where exactly do you see the problem to feed parts of documents into
> > the parser and merge the resulting tree with an existing one?
>
> I could not see a way with QXmlReader to parse only a part of the
> document. 

Where is the problem here? We have find a smart way to detect which part of 
the document is damaged and only feed this substring into the parser. I think 
it is not much different from what we have now.


> Merging has to be done by us anyway. 

Yes, true.

> > This is what I would call the builder :-)
> > If we could use the existing builder for KDOM we could save some
> > work.
>
> But as KDOM is not yet available and I have some doubts about the
> possibility to fit clearly for our case (unless someone proves me
> wrong), I would suggest to completely write our own code.

Can you please elaborate more on your doubts? Especially after reading Frans 
mail.


> > This is the point that could become hard from what I know in the
> > moment. But I see no real blocker here.
>
> If it is possible to insert nodes in whatever position you want, or to
> move nodes (and their children), then it is doable.

I assume that any DOM tree has this ability. Where comes your suspicion from 
that KDOM can not do it?


> > So still the question how to proceed? We can not use KDOM2 yet and
> > creating our new parser with our custom dom tree was the last idea.
> > Do you still want to go this way?
>
> Yes, but in a way that our custom DOM tree can be easily replaced by
> KDOM once we switch to Qt/KDE4.

Here are my concerns. I think it is not good to invest a lot of work in our 
custom DOM tree. From my POW there are two ways to go: Either we can reuse 
most of the DOM tree we have yet or we should postpone the work on the parser 
to KDE 4 in order to use KDOM from the beginning. 


> > I am not so sure anymore, because I
> > fear that we make a lot of work that will be thrown away when we
> > switch to KDE4.
>
> We don't have to throw that away. KDOM is needed for VPL, but as I
> understood it will be really useful only if KHTML is based on KDOM as
> well (which is currently not). So I suggest to make a clear
> architecture and code for parsing and tree building. 

I don't really understand this. My understanding is/was that we want only one 
tree. This one must be the tree that is used for rendering. Frans says it is 
very likely that this will be KDOM. So we could start a discussion about this 
in k-core-dev to make sure this will happen. I believe that if we decide for 
Quanta that we want to use KDOM this is another argument for using KDOM in 
KHTML for KDE 4 and makes it almost sure that this will happen. Given the 
current manpower for KDE 4 we might have to help though ;-) 

But this is the future. What we have to decide now is what to do for a Kuanta 
release. 

From my current understanding the clear architecture should be:
1. create a reader that operates on a texteditor
2. create a tag soup parser 
3. create a builder that builds our current DOM tree so that we can reuse the 
rest of the code. This builder should implement the builder interface of the 
KDOM builder.

Partial parsing is optional for me for this testing release. We probably need 
it for KDE 4.


> The rest is detail. ;-)

What would the world be easy if there wouldn't be so many details ;-)


Jens

[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]