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

List:       quanta-devel
Subject:    Re: [quanta-devel] first thoughts about Quanta -> KDevelop
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-05-09 18:21:43
Message-ID: 200505092121.48799.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 09 May 2005 21:03, Frans Englich wrote:
> > I don't have plans yet for it as I never looked at KDOM. But we
> > cannot even think about using it unless it is moved to kdelibs.
> > Mostly because we need a stable library. No, I don't know if it's
> > stable now or not, but we cannot take the risk.
>
> On kfm-devel Laffoon wrote:
>
> "At many points we have had to make design decisions based upon what
> is available and what our objectives are. Often there are some very
> cool things being developed in KDE that we would like to use, but we
> find that the scope is not wide enough or there is some small factor
> indicating the need to develop a tool or library ourselves. [...] I'd
> like to have ongoing communication in these areas."
>
> And I think this is a case where we should have a closer look. I
> mean, it would be a pity if Quanta/KDevelop built a new architecture
> around an old DOM implementation, 

The current plans are not building anything new around an old DOM 
implementation. There isn't a real DOM implementation anywhere in 
Quanta, it's a parser that fulfills Quanta's needs and happens to use a 
tree-like representation of the document. But as it holds information 
for non-XML elements as well, I can hardly call it a real DOM tree. 

> instead of a one with better 
> design, more functionality, and SVG, XPointer, XInclude, OASIS XML
> Catalogs, XPath, sitting on top.

So the real question is: will KDOM fit Quanta's needs? I cannot give an 
answer until I look to KDOM more deeply, and I think this will happen 
only when we start to port Quanta to KDevelop: for the KDE4.

> Is KDOM stable?
>
> Quite some XML implementations passes their test suites and they use
> KDOM. IIRC, KDOM passes the DOM 2 Core's test suite; Rob can probably
> fill in the details. You will find incompleteness in DOM 3 Core and
> DOM 3 Load and Save, but KHTML's DOM doesn't even have that.
>
> The API is in most cases plain W3C DOM and hence stable. The only
> case I can think of that may change is the internals of XPath which
> currently is in development.

The stability is about API stability. If it's outside of kdelibs noone 
can guarantee that:
- it will be present on the user's computer 
- it will not have a different release schedule than KDE, meaning that 
we don't have to support more versions with different API versions.

It already happened with libxml2 that I had to add ifdef's due to 
changes in the API, altough libxml2 is a basic dependency for the whole 
KDE, not only Quanta.

> Allan Sandfeld Jensen writes on kfm-devel about discussing the future
> of KHTML & KDOM; and common sense tells a kdelibs inclusion is
> sensible.

That will be a good point for KDOM from my point of view.

> My point: I think it would be regrettable and a waste of work if not
> an evaluation happened early, before a KDevelop merge, or that
> Quanta's needs weren't addressed. Is KDOM stable? Just ask about the
> specifics, or anything else.

The short thing about what Quanta needs is fast and on-the-fly 
rebuilding of the DOM tree. Quanta works with a live, ever changing 
document, while KHTML and many other applications work with a rather 
static document. They can change, but not so fast and a different way 
like in a text editor. 
 Other issue is the ability to have information about non-XML elements 
(like PHP functions, classes, CSS selectors, attributes, whatever) in 
the tree.
 So maybe you could give us a basic introduction what is exactly KDOM, 
what can one do with it and how can we use it. 
 
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]