[Kst] PATCH: inconsistent font sizes

[George Staikos]

On Saturday 04 February 2006 00:34, Barth Netterfield wrote:
> Actually, this is not related to the stale info bug.
>
> The issue here is that the axis labels have to use 'geometry' to determine
> the font size: they can't use the content rect because the content rect
> depends on the axis label size... its recursive, with no promise of
> convergence (given integer font sizes).  But this is fine.  The axis labels
> do, and always have used geometry.  No problem.
>
> The problem was that the other labels had chosen to use contentsRect for
> the size.  Also no problem in and of itself.  The only (minor) problem is
> that that font size 0 for a child label will be smaller than font size 0
> for an axis label.  Not perfect.
>
> So the patch just says "if geometry is good enough for the axis labels
> size, its good enough for child label size."
>
> This has nothing to do with where we place the labels though.

   If we compute the size of the contentsRect in updateSelf(), which means 
computing the size of axis labels there, then we will have a valid 
contentsRect for the movable labels.  The movable labels get updated after 
the parent is updated.

    The order is presently:

paint:
   updateMyself()
   for each child:
      paint()
   paintMyself()


   The problem is that Kst2DPlot mixes update and paint.  If we updated first 
- and that includes axis label calculations - then the contentsRect will be 
valid.  That was, in effect, the main point of all the painting reworking 
from the beginning.  It had to be made into a two-phase operation.  Kst2DPlot 
was too messy to change further than I did, but maybe we have to try anyway.

   Axis alignment will have to be computed before the paint happens, and that 
is the case right now.

   You can see how necessary the painting reworking was...  We could never 
have implemented contentsRect relative resizing/moving or proper clipping of 
objects without it.  There was a lot of ping-pong happening in the painting 
code refixing and rebreaking various things because a one-phase update+paint 
results in the wrong thing in one case at all times.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/