duncan.hanson at gmail.com
Thu Jun 1 02:34:42 CEST 2006
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
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5802 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20060601/4ca2122c/attachment.bin
More information about the Kst