Review Request 119527: Added feature of creating report's items of specific size at adding time
Jarosław Staniek
staniek at kde.org
Sat Aug 2 22:48:00 BST 2014
> On July 29, 2014, 6:19 p.m., Jarosław Staniek wrote:
> > libs/koreport/items/check/KoReportDesignerItemCheck.cpp, line 53
> > <https://git.reviewboard.kde.org/r/119527/diff/1/?file=293998#file293998line53>
> >
> > 1. How about moving this code to KoReportDesignerItemRectBase ctor?
> >
> > And add virtual QSizeF KoReportDesignerItemRectBase::minimumSize() const = 0; which you'll implement in subclasses. There, sometimes you want to return getTextRect().size(), sometimes yoyu want to return QSizeF(5, 5), etc.
> >
> > 2. m_userWidth/m_userHeight are not needed if you can just use r->countHeight() and r->countWidth(). That's typical overuse of member variables.
> >
> > 3. Give the fixes I propsed below, m_user* members can be equal to -1. Check this and if either is -1, use default size.
>
> Wojciech Kosowicz wrote:
> This is the situaion that occurs:
> 1. setRectScene must be called in constructor's init. Before all the values are set for 0
> 2. KoReportDesignerItemRectBase::minimumSize() I propose to return QRectF
> 3. To return QRectF I would need two more member variables
> m_userHeight = r->countHeight();
> m_userWidth = r->countWidth();
> m_pressX = r->m_pressX;
> m_pressY = r->m_pressY;
> theoretically by modyfying init(giving it specific pointer) method I could use them without writing theirs values to member variables but it be would rather significant change in reports. and I would still need pressX, pressY members :)
> 4. Regarding second point I agree to initialize members to -1 but I think the way I proposed of checking for minimum size by comparison to minimum value is enought
>
> By the way when I learnt about design patterns :)about year and also thought of using template method here :) I didn't propose it as I wanted your opinion but I'm glad it came up :)
> I would like to share your opinions regarding the points presented above as any change here goes with changes within about 20 files so I would like to have it more or less clear when starting modification:)
>
> Regards :)
> Wojtek
>
> Wojciech Kosowicz wrote:
> The solution above would also require two new getters for m_pressX and m_pressY
setRectScene must be called in constructor's init. Before all the values are set for 0
Then it can be moved to KoReportDesignerItemRectBase::init(), right?
KoReportDesignerItemRectBase::minimumSize() I propose to return QRectF
If the position of the rect is always equal to (r->m_pressX, r->m_pressY), then there is no point in returing rect, right? Size is enough.
Or do you expect some implementations will return some other position?
To return QRectF I would need two more member variables
m_userHeight = r->countHeight();
m_userWidth = r->countWidth();
m_pressX = r->m_pressX;
m_pressY = r->m_pressY;
theoretically by modyfying init(giving it specific pointer) method I could use them without writing theirs values to member variables but it be would rather significant change in reports. and I would still need pressX, pressY members :)
No opinion for now untill we decide if we return QSizeF() or not, see above.
Regarding second point I agree to initialize members to -1 but I think the way I proposed of checking for minimum size by comparison to minimum value is enought
OK
By the way when I learnt about design patterns :)about year and also thought of using template method here :) I didn't propose it as I wanted your opinion but I'm glad it came up :)
I would like to share your opinions regarding the points presented above as any change here goes with changes within about 20 files so I would like to have it more or less clear when starting modification:)
OK!
- Jarosław
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119527/#review63448
-----------------------------------------------------------
On July 29, 2014, 12:24 a.m., Wojciech Kosowicz wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119527/
> -----------------------------------------------------------
>
> (Updated July 29, 2014, 12:24 a.m.)
>
>
> Review request for Calligra, Adam Pigg and Jarosław Staniek.
>
>
> Bugs: 334967
> http://bugs.kde.org/show_bug.cgi?id=334967
>
>
> Repository: calligra
>
>
> Description
> -------
>
> If the specified dimensions are improper or too small elements get their defaults size
>
>
> Diffs
> -----
>
> libs/koreport/items/check/KoReportDesignerItemCheck.cpp 5bebc6c
> libs/koreport/items/field/KoReportDesignerItemField.cpp 0dc9325
> libs/koreport/items/image/KoReportDesignerItemImage.cpp 87e46a1
> libs/koreport/items/label/KoReportDesignerItemLabel.cpp 8974a80
> libs/koreport/items/text/KoReportDesignerItemText.cpp 51e12d3
> libs/koreport/wrtembed/KoReportDesigner.h adc712a
> libs/koreport/wrtembed/KoReportDesigner.cpp 63152a7
> libs/koreport/wrtembed/KoReportDesignerItemLine.h 894cec9
> libs/koreport/wrtembed/KoReportDesignerItemLine.cpp 1b0474d
> libs/koreport/wrtembed/KoReportDesignerItemRectBase.h b53a58e
> libs/koreport/wrtembed/KoReportDesignerItemRectBase.cpp 53c3727
> libs/koreport/wrtembed/reportsceneview.h cc3ab9f
> libs/koreport/wrtembed/reportsceneview.cpp 2b679a4
> plugins/reporting/barcode/KoReportDesignerItemBarcode.cpp b4fb621
> plugins/reporting/maps/KoReportDesignerItemMaps.cpp f624db3
> plugins/reporting/web/KoReportDesignerItemWeb.cpp 63e1cc9
>
> Diff: https://git.reviewboard.kde.org/r/119527/diff/
>
>
> Testing
> -------
>
> When adding any element in kexi report it will the same size as specified by the user at the moment of adding
>
>
> Thanks,
>
> Wojciech Kosowicz
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20140802/3910649a/attachment.htm>
More information about the calligra-devel
mailing list