[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:       Frans Englich <frans.englich () telia ! com>
Date:       2005-05-09 18:43:03
Message-ID: 200505091843.03627.frans.englich () telia ! com
[Download RAW message or body]

On Monday 09 May 2005 18:21, Andras Mantia wrote:
> 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.

One approach is perhaps how KSVG2 does; customizing the implementation with 
its own interfaces(an XSL-T implementation would build a stylesheet in a 
similar way).

Another could be the interfaces DOM 3 Core offers for exactly this purpose;

http://www.w3.org/TR/DOM-Level-3-Core/core.html#UserDataHandler


However, Niko and Rob answers these questions the best, since KDOM were 
designed with things like this in mind(keep the CC).


Cheers,

		Frans


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