From koffice-devel Mon Apr 23 06:24:56 2007 From: Thomas Zander Date: Mon, 23 Apr 2007 06:24:56 +0000 To: koffice-devel Subject: Re: Image shape (was: Re: koffice) Message-Id: <200704230824.56442.zander () kde ! org> X-MARC-Message: https://marc.info/?l=koffice-devel&m=117730956202915 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1638826849==" --===============1638826849== Content-Type: multipart/signed; boundary="nextPart2274314.vS5A4pPIKq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2274314.vS5A4pPIKq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 KWord. See; I made the deal with Allen to print the next ev quarterly using=20 KWord2, and images are required for that. The idea that Cyrille stated (backup shape) is essentially what I did.=20 With a slight change for KWord. In KWord the user gets to choose if he=20 wants to use a krita shape for his images at runtime. So if he doesn't=20 edit anything, he doesn't load the (rather heavy) krita shape. This additionally gives users the advantage that I can show a low res=20 version of the image on screen and thus avoid a document taking a lot of=20 memory. As the loading of the larger images only takes place when it is being=20 drawn the first time loading of a document with many images should=20 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.=20 Well, I'm happy to put your mind at ease; as that is not what is=20 happening. To be correct that is a KoImageData not a KoImage. I don't=20 mean to be pity, but this distinction in name is relevant about what the=20 class does; it (just) holds pointers to the file data and maybe a QImage=20 for the full data if the image is small. It also is a generic interface (a KoShapeUserData inheriting class) that=20 applications can talk to. Something that is impossible with plugins=20 otherwise. It is not meant to be more than that. > I wonder if there is a reason why kotext can't be moved=20 > 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=20 explain what I've been doing. The thing I have been doing is that all the code for the text part has=20 been moved to the plugin, where possible. Similar to the picture plugin=20 we talked about above, there needs to be an public API that the apps can=20 cast to in the shape of some 3 classes. Additionally there is a (re)implementation of what KWord does in the libs. = =20 Really, there is a second text-layout code block that is unused in KWord=20 and is there solely for the benefit of the other koffice apps.=20 There is an ongoing effort to move more to the plugin, and the parts that=20 are still there are essentially a public API and an implementation for=20 apps other than KWord. (for example, there is a font dialog that I should=20 still move) So, bottom line, kotext as we knew it in KOffice1.x already has moved to=20 the plugin. =2D-=20 Thomas Zander --nextPart2274314.vS5A4pPIKq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBGLFE4CojCW6H2z/QRAh6oAKDeh7Gdxasz50Nz+Lz/I6xSpmYk+wCeIr/2 7PouO0Bo1/7dPGxT18mG9iM= =bC+z -----END PGP SIGNATURE----- --nextPart2274314.vS5A4pPIKq-- --===============1638826849== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============1638826849==--