[Kst] branches/work/kst/viewaspect/kst/src/libkstapp

[Duncan Hanson]

On Wed, 2006-05-31 at 17:00 -0400, George Staikos wrote:
> On Wednesday 31 May 2006 13:35, Duncan Hanson wrote:
> > I think I have basically finished what I intended to do (repair bugs
> > BUG:128086, BUG:127524). The issue was that the maintain aspect modifier
> > was not strictly enforced. The simplest solution was to determine aspect
> > maintaining sizes from both the x and y positions of the mouse (whereas
> > previously I think that it was done using only x).
> 
>   If you're completely done, I will do a diff and review.  If it's stable and 
> looks good, I'll merge it into trunk.  It might not be included in the next 
> release though.

I haven't found any bugs, and the bulk of the changes have been made. If
you can look at it soon that would be good. I will hold off making any
more changes until I've heard back.

> > While I was fixing the bugs, I cleaned the code up as well. The view
> > objects have a slew of different ways to handle their creation and
> > resize. I've brought these together into KstGfxMouseHandlerUtils and
> > eliminated some reproduction by basing all resizes around an anchorPoint
> > and a movePoint.
> 
>   It's always best to do this cleanup as separate commits and well-documented.  
> It's a shame if they prevent a patch to go in.  Also it's important to be 
> sure that the different cases of resize didn't have purposesly different 
> semantics.
> 
> > As long as this branch is here for us to fool around in, do you think it
> > might be worthwhile to repair some of the FIXME's in ksttoplevelview?
> 
>   If you want to do that, and I think it would be -great- to make 
> ksttoplevelview object-independent, please make sure it's clear which patches 
> apply to which work so that it can be cleanly diffed.  If in doubt, make 
> another branch.
> 
> > KstTopLevelView::pressMoveLayoutModeCenteredResize. My suggestion here
> > is to implement a fast virtual KstViewObject::paintForResize(KstPainter&
> > p, const QRect& oldgeom, const QRect& newgeom) const; method and use
> > polymorphism.
> 
>   What do you mean?

I've included a patch. I suppose the objection can be made that the
KstViewObject is drawing outside its bounds, but the bounds into which
it draws are dictated by a KstTopLevelView, so ultimate control is still
in the proper place.

> > Another example of KstTopLevel view knowing about specific 
> > viewobjects is in KstTopLevelView::pressMoveLayoutModeEndPoint, when the
> > viewobject must be typecast to a KstViewLine. Why don't we move all the
> > resizing code into the view objects themselves. 
> 
>   Yes please, I was meaning to do this at some point!

It will probably be best to work out this (and the painting) in a
separate branch. Can you create one from for me from the viewaspect
branch (or from the trunk if you end up merging)? Maybe call it the
resize branch.

Cheers,
Duncan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resize_painting_example.diff
Type: text/x-patch
Size: 5802 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20060601/4ca2122c/attachment.bin