KDE 4 Development book

[Eric Laffoon]

On Saturday 13 November 2004 02:12 pm, Frans Englich wrote:
> On Saturday 13 November 2004 19:28, Eric Laffoon wrote:
> > On Saturday 13 November 2004 04:33 am, Frans Englich wrote:
> > > On Friday 12 November 2004 22:58, Eric Laffoon wrote:
> > > > On Friday 12 November 2004 08:35 am, Andras Mantia wrote:
> > > > > On Friday 12 November 2004 18:05, Frans Englich wrote:
> > > > > > Back to editors; right, there is a general lack of open source
> > > > > > XML editors(but many good, cross-platform, proprietary ones), I
> > > > > > have some vague memory of Quanta though. I guess the solution is
> > > > > > to simply write open source ones..
> > > > >
> > > > > Once I make Quanta work with entities it should be quite OK for
> > > > > editing complex docbook. You can already do it, but it doesn't help
> > > > > with entities. But it can be set up to validate the document
> > > > > structure as you type and run other validators from inside.
> > > > >
> > > > > Andras
> > > >
> > > > It can also contain a complete set of templates, markup abreviations
> > > > and scripted automation. Carlos Woelz has also created DocBook
> > > > toolbars. In addition to this Paulo Moura Guedes is now involved full
> > > > time in VPL development with one of the tasks on his do list to
> > > > enable an XSL translation layer. This would in theory enable visual
> > > > editing of DocBook files with an HTML representation. Quanta projects
> > > > can also include internal documentation and other resources too.
> > >
> > > I thought about GUI editing by reverse mapping an XSL transform, but I
> > > quickly discarded it as a horror to implement.. :) Another way of doing
> > > GUI Docbook editing is to use the Docbook CSS; Docbook XML directly
> > > rendered via CSS. The result is very nice and can be used in
> > > production, as long as it's simple(no index, footnotes, etc, articles
> > > typically works fine).
> >
> > Yes, the XSL transform approach is nightmarish, but then creating a good
> > visual editor isn't exactly a walk in the park. For us the XSL layer
> > would be one more where there are already several layers being managed.
> > The CSS approach would have less flexibility in rendering in several
> > areas, but it could be workable. I haven't tried it but it should be
> > possible to do it in Quanta now provided KHTML supports XML/CSS. I know
> > it did not earlier. Does it now?
>
> I asked about this on kfm-devel; I'm not quite sure what the answers mean
> in practice:
>
> http://lists.kde.org/?l=kfm-devel&m=109947837206137&w=2
>
>
>   Frans

Hi Frans,
This is rather interesting. It appears to mean that a very basic visual 
implementation with XML/CSS should be possible now and we should try it to 
make sure that there are no unforseen problems. Beyond that there is the 
expected confusion about how best to proceed but there seem to be a lot of 
exciting things going on. For us the good news is that the XSLT 
implementation could be nearly automatic in the future if KHTML supports it 
and this is very good news.

I'm copying to our list. We should coordinate and see what we can come up with 
for an editing package. 
-- 
Eric Laffoon - Quanta+ Team Leader 
http://quanta.sourceforge.net  sequitur at kde.org
Mailing list - http://mail.kde.org/mailman/listinfo/quanta
GPG Fingerprint: 48FB 218D 747F A54A 319D EE98 4A25 794E A453 004B
http://quanta.sourceforge.net/developer/keys/Eric_Laffoon_pubkey.asc