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

List:       koffice-devel
Subject:    Re: Help needed with KSpread zoom
From:       John Dailey <john.dailey () dnamerican ! com>
Date:       2002-06-12 17:23:57
[Download RAW message or body]

This looks like a good plan, and there is no particular reason not to use the 
same hack with background color/brush.  We can also use a -1 with zoom < 0.5.
I actually think Norbert used this same idea in some of his commit.

By the way, you can notice that in high zoom, the painting problem disappears 
when the window is covered by another application, then uncovered -- showing 
the problem to be that the old data was never cleared.

> AFAIK it's not the clearing, it's the missing/overwritten background. So it
> wouldn't help to clear the foreground, if the background is still missing.
>
> So what I would suppose for a quick hack would be:
> 1. Pass the zoom value to cellPaint
> 2. If zoom > 1.5 then paint background always with width+1/height+1.
> 3. If zoom <> 1.0 repaint right/bottom border too.
>
> Result of the hack would be:
> 1. Minimal intrusive
> 2. Performance penulty only when zoom <> 1.0
> 3. Only one problem: Colored background would overlapp next cell when
> zoom >1.5, but this would only be visible when there is no border
> (otherwise the border overpaints the background).
> Only 3. would lead to some BR and we can handle this I think.
>


Seems to me this way too, but I think we'll eventually be able to work around 
it.  Notice now that the KSpreadView is already passed into the painting 
functions now so we can easily get the zoom value.  Just be aware that it may 
be a NULL pointer if painting wasn't initiated from a view (like from a print 
command).

> I get more and more the impression, that this is a bug in QT. We have the
> code:
>   QBrush bb = backGroundBrush( cellRef.x(), cellRef.y() );
>
>   if( bb.style() != Qt::NoBrush )
>   {
>     painter.fillRect( corner.x(), corner.y(), width, height, bb );
>   }
>
> Why is between fillRect (0,0,60,20,bb) and fillRect(60,20,60,20,bb) an
> empty line on screen at the lines (119,0,120,40) and (0,39,120,40), when we
> have painter.scale(2.0,2.0)? I rather thinking of a rounding bug in QT now,
> as this behaviour is really strange. But I didn't test with simple code yet
> to prove this issue.
>
> > Of course, if we start painting in coordinates scaled to the zoom then we
> > *will* need the doubles.
> >
> > > > I'll see what I can dig up on the embedding zoom problem tomorrow.
> > > > Hopefully that will be simpler to fix!
> > >
> > > Fine.
> > >
> > > Let's try to fix it.
> > >
> > > Again my hope, that David or Laurent can say something about how
> > > KPresenter and KWord is handling zoom, as when we start to
> > > reprogramming, I don't like to change everything and then see that it
> > > should have been done
> > > differently.
> >
> > I see David's email....that looks helpful.
>
> Yes, very helpful. I will see what I can do until Sunday.
> For the Beta2, can you try my above described "hack" and upload it, while I
> will try to move to the real zoom values and upload it after Beta2 is
> tagged/released?
>
> Philipp
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
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] 

Configure | About | News | Add a list | Sponsored by KoreLogic