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

List:       koffice-devel
Subject:    Re: New KoPicture code
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-03-11 20:30:57
[Download RAW message or body]

On Monday 11 March 2002 18:41, David Faure wrote:
> On Sunday 10 March 2002 21:08, Nicolas Goutte wrote:
> > I have finished the first code for KoPicture.
> >
> > I have the code for lib/kofficecore and for KWord. KPresenter is not
> > touched and can still work with KoImage/KoClipart.
> >
> > My question now is how to put in CVS.
> >
> > Does someone want to see the code first? (patch for lib/kofficecore: 50KB
> > uncompressed, 10KB bzipped, patch for KWord is much smaller but I have it
> > against an one week old version (at least for now.)
> >
> > I also know that David Faure prefers when files created from other files
> > are not added like that in CVS.
>
> Well, if most of the file's original code is still there, copying on the
> server allows to preserve history. But for KoImage/KoClipart there isn't
> much to preserve anyway. And copying on the server is easier if done before
> the hacking, not after. Let's skip it for this time, feel free to commit -
> well, after fixing the resizing problem mentionned below ;)

That is why I asked. I had no idea if you wanted to preserve the history of 
those files or not. And as I knew that after a commit, you have to hack the 
CVS files themselves, I was waiting.

>
(...)
>
> > - possibility to create other classes for other type of picture like WMF
> > (the outside class remains KoPicture!)
> > - fixed a few drawing bugs. The drawing is now make systematically from
> > the loaded (called "original") image. There is no more the consecutive 
> > resizing of the image.
>
> Ouch. I'm not sure this is a good move. The idea of resizing the image to
> the current screen size was that it makes it much faster to redraw. If the
> image has to be resized during every paint event, things are going to get
> much much slower. Please readd the whole logic for keeping a cached resized
> version of the image, for the painting.

Perhaps I was not clear. For bitmaps, I have a cached QPixmap, but it is 
created only when the image is about to be displayed and that the cached 
version has not the right size. The old code immediately re-sizes (and copies 
QImage objects.)

I find the result a little faster, but that is may be system-dependant.

> Note that resizing was never "consecutive", the image was always resized
> from the original image, that was the whole point of this class. Please
> consider reverting to the initial behavior for this.
>
> > - Again QPicture compatibility with KOffice 1.1.x

To be clear: the compatibility is only for WMF files, as SVG files are 
exactly saved back, as they were loaded.

>
> Good.
>
> > What has not changed:
> > - KPresenter
> > - The difference between image and clipart in KWord
>
> Can easily be changed afterwards if the underlying class is the same.

Yes, it is! :-)

>
> > Know bugs:
> > - kword/kwtextimage.* has surely been broken (and I cannot test, as I
> > have not file with this sort of images.)
>
> Yeah, it's not possible to create any of those anymore anyway, it's an old
> koffice-1.0 thing (and 1.1-beta1 or so). I wanted to create some automated
> conversion to a frame containing an image, but time passing I think we
> might just throw this away.

It might be good, as it is the only place that really needs to store the size 
in the KoPicture object (apart of the size of the cached QPixmap for 
bitmaps.).

Have a nice day/evening/night!
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]