KFlowRects proposal (planned for next Monday)

[Richard Dale]

On Tuesday 07 August 2007, Andreas Pakulat wrote:
> On 07.08.07 08:39:55, Thomas Zander wrote:
> > On Monday 06 August 2007 23:24:13 Matthew Woehlke wrote:
> > > > Sounds like a bad idea.  (the moving code, not the getting rid of).
> > > > Creating a new class in ui for something that Qt is pretty capable of
> > > > doing is not my idea of cleaning up.
> > >
> > > If Qt can do it then removing it is correct... but I'm not familiar
> > > with Qt providing this functionality. Maybe instead of just saying
> > > "that's a bad idea, Qt can do this" you could specify *how* Qt can do
> > > this?
> >
> > Sorry for being unclear; the mail from Matt on this thread gave a for 3
> > lines of code QRect solution that seems like a great base to me.
> >
> > I'm also a bit troubled by the fact we are already in freeze when you
> > propose code that you have not written yet, has no API that is actually
> > used by more then you so it didn't get a whole lot of peer review.  And,
> > no, I don't think that emails to this or any mailinglist are a good
> > substitute for that. ;)
> >
> > I suggest you wait until 4.0 is out the door and postpone the search for
> > a (kdelibs based) solution to after that point.
>
> You didn't get the idea did you? If kdefx is not removed now (which has
> users, who have to have some replacement to not drop features), KDE4
> will have it always. There is a replacement in the works for KDE 4.1,
> but it has to be removed for 4.0.
>
> So the choice is either just removing it (moving KStyle to kdeui)
> blindly and having a few modules in trunk/KDE not build until someone
> ports them to Blitz (as external dependecy) or drops the code that used
> kdefx-classes.
>
> Matthew just tries to put some of the code which is not in Blitz into
> another library (i.e. kdeui) in kdelibs so that users of that code can
> be ported instead of break.
>
> So far Matthew didn't propose to add new untested code, he proposed to
> move, rename and cleanup a class from kdefx.
But we don't have to add another public class to kdelibs to do that. We could 
just port the existing code to use the one line suggested by Mat Newell:

On Monday 06 August 2007, Matt Newell wrote:
> Why such a longwinded api for something so simple.
>
> QRect getFlowedRect( int index, const QSize & itemSize, int layoutWidth,
> int h_spacing, int v_spacing )
> {
> 	int itemsPerRow = layoutWidth / (itemSize.width() + h_spacing);
> 	return QRect( QPoint( (index % itemsPerRow) * (itemSize.width() +
> h_spacing), (index / itemsPerRow) * (itemSize.height() + v_spacing) ),
> itemSize ); }
>
> Seems to me that it's so simple it'd be better off put in a wiki and copy
> and pasted for people to use inline who need 

Once a class like this is added to kdelibs it will be very difficult to remove 
it, because it doesn't cover functionality that will be in either blitz or 
quasar. If it isn't a particularly useful or well designed class, and we are 
in the middle of a code freeze, we shouldn't subvert the normal kdelibs 
review processes.

-- Richard