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

List:       koffice-devel
Subject:    Re: OASIS file format for Krita
From:       David Faure <faure () kde ! org>
Date:       2004-03-22 11:54:00
Message-ID: 200403221254.00860.faure () kde ! org
[Download RAW message or body]

On Monday 22 March 2004 12:36, dirk.schoenberger@sz-online.de wrote:
> Embedding - I think that's the basic problem I (and James?) have.
> Basically I think embedding is to limited to be useful.
> With limited I mean:
> - it is to coarse grained. Basically an embedded element is a rectangular
> element in a document which provides its own user interface (toolbars,
> menubars) and its view. You cannot use its inner functionality, for say,
> vector editing in KPresenter, so basically each KOffice component has to
> implement its own rendering model.
Yes, but this can be shared even with the current embedding system.

> - Its rendering model is limited to that of QPainter, i.e. basically
> integer coordinates, pixel wise access and explicit transformations.
> So you cannot simply create a more featureful rendering system (basically
> something used in Karbon14/KSVG/KPainter - floating point coordinates,
> implicit transformations for image and vector data)
Yes. But surely one could have a KPainter-like rendering model draw into
a QPainter, no? In the end you still get to pixels...

> - Embedded documents don't know enough about their parent document. E.g.
> if you embed a spreadsheet component in KWord, the embedded document shows
> a full KSpread document, when all you wanted would be a 10x10 spreadsheet
> view / table grid.
This possibly needs panning (see the thoughts file in kofficecore) and limiting the size 
of a kspread document.

I'm not saying the current system is perfect, I agree with you about all the things
that need to be done to it.

> - window/document/view framework - I think with the added concept of tools
> and actions this would be useable also outside of KOffice, i.e. a good
> candidate for kdelibs.
Maybe a very basic framework could make sense for kdelibs, but not the full-fledged
koffice framework. The main requirement koView adds, compared to a simple
"widget to view a document" is the support for zooming (and other transformations),
which basically requires a real rendering model with separation between the
data (e.g. in points) and the result (in pixels). That's what defines KOffice, and
I don't see use for it in non-KOffice applications. E.g. even in Kolourpaint
supports zooming, surely it doesn't use points and double coordinates for its data.
It doesn't embed other koffice components, either.

But I agree that a basic doc/view/window framework _could_ be extracted from 
the KOffice one, if there was enough interest in it; this would be an intermediate
layer between KParts (one widget per part) and KOffice (support for embedding
and zooming, ZIP store, etc.). I'm just not sure there is enough interest in this.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]