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

List:       koffice-devel
Subject:    Re: Image shape (was: Re: koffice)
From:       Thomas Zander <zander () kde ! org>
Date:       2007-04-23 6:24:56
Message-ID: 200704230824.56442.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 22 April 2007 21:33, Cyrille Berger wrote:
> > It _sounds_ like all flake using applications will have to come up
> > with some way to "upgrade" a simple picture shape to a krita shape if
> > the user wants it color managed filtered or something like that, and
> > it _looks_ like we'll have a "simple" and a "complex" image shape in
> > the shape selector and so on.
>
> The way I see it, people have krita installed, images are loaded in a
> "krita shape", krita isn't installed, images are loaded in a backup
> image system. And people with krita install will have more features.
>

Seems a lot of confusion has risen around my work to restore images for 
KWord.
See; I made the deal with Allen to print the next ev quarterly using 
KWord2, and images are required for that.

The idea that Cyrille stated (backup shape) is essentially what I did. 
With a slight change for KWord.  In KWord the user gets to choose if he 
wants to use a krita shape for his images at runtime.  So if he doesn't 
edit anything, he doesn't load the (rather heavy) krita shape.
This additionally gives users the advantage that I can show a low res 
version of the image on screen and thus avoid a document taking a lot of 
memory.
As the loading of the larger images only takes place when it is being 
drawn the first time loading of a document with many images should 
already have a major boost in speed.

> I don't like the idea of moving kritaimage to a koimage, I see no point
> in that move. 
Well, I'm happy to put your mind at ease; as that is not what is 
happening.  To be correct that is a KoImageData not a KoImage. I don't 
mean to be pity, but this distinction in name is relevant about what the 
class does; it (just) holds pointers to the file data and maybe a QImage 
for the full data if the image is small.
It also is a generic interface (a KoShapeUserData inheriting class) that 
applications can talk to. Something that is impossible with plugins 
otherwise. It is not meant to be more than that.

> I wonder if there is a reason why kotext can't be moved 
> to shapes/text (or whatever else the shape is).

I can see how this context has been lost in the many commits, so let me 
explain what I've been doing.
The thing I have been doing is that all the code for the text part has 
been moved to the plugin, where possible.   Similar to the picture plugin 
we talked about above, there needs to be an public API that the apps can 
cast to in the shape of some 3 classes.
Additionally there is a (re)implementation of what KWord does in the libs.  
Really, there is a second text-layout code block that is unused in KWord 
and is there solely for the benefit of the other koffice apps. 
There is an ongoing effort to move more to the plugin, and the parts that 
are still there are essentially a public API and an implementation for 
apps other than KWord. (for example, there is a font dialog that I should 
still move)

So, bottom line, kotext as we knew it in KOffice1.x already has moved to 
the plugin.
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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