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

List:       koffice-devel
Subject:    Re: playground/office/flake/lib
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2006-04-23 6:27:24
Message-ID: 200604230827.24996.t.zachmann () zagge ! de
[Download RAW message or body]

Hello,

On Sunday 23 April 2006 01:52, Thomas Zander wrote:
> On Saturday 22 April 2006 18:16, you wrote:
> > Hello,
> >
> > On Saturday 22 April 2006 08:50, Thomas Zander wrote:
> > > I think this commit is wrong.
> >
> > I don't think so :-)
> >
> > > First; you removed my code that made sure the distance between the
> > > object and the handles was kept stable. (m_handleDiff)  Why would you
> > > just remove it?
> >
> > You remember that it broke for rotated objects.
>
> So? Having code that fixes zooming but later found to still have a bug in
> rotation is no reason to remove the code. IMOHO. Now we have problems
> with zooming again.

That is why I added a comment that it needs to be fixed. I also planned on 
fixing it, but had no time left to do it.

> I guess you don't want me to follow your example, do you? ;)
> Please have some respect for other peoples contributions and if you don't
> understand an algorithm please ask instead of just redoing it.

I'm sorry fix if you felt I don't respect your contributions. I do respect 
them. 

I have fixed the problem now.

> > > Next: The reason we had
> > >   QPointF m_selectionBox[8];
> > > in the KoGraphicsBase was so subclassed objects could have a
> > > different outline and a different positioning of the handles based on
> > > the object type it is. (you can see that by the fact that they were
> > > protected, not private)
> >
> > I don't think the object itself needs to have the handles for the
> > selection. It is the task for the selection.
>
> This is very much about the outline, not the handles. Imagine having 50
> objects in a selection, most of them overlapping.  How usefull do you
> think it is if all of them have square outlines?

Ok I think we agree here. The method was called paintSelectionHandles so it 
was there for painting the handles. As this is now done in the selection 
where it belongs too, I saw no reason for keeping it there. 

I also agree that we need a method for showing that an object is selected. 
That is why I posted a question about this on the mailing list at the 20. 
April with the title Flake.

I think we should rename the method paintDecorations to paintSelction and use 
this method for showing that an object is selected. The connection paints are 
only shown as an example they will not be shown in the end.

> > I think we only need one type of selection and it is a rectangular.

As said we should discuss this in the threat I mentioned above.

Have a nice Sunday,

Thorsten
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]