> On April 28, 2012, 6:52 a.m., Marko Käning wrote:
> > This looks all sensible to me.
> >
> >
> > And yes, why wouldn't one want to use this approach:
> >
> > > -why are the month names as translatable strings in there, isn't it
> > > enough to call QDate::longMonthName()?
> >
> >
>
>
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103622/
---
(Updated Dec. 9, 2012, 1:25 p.m.)
Review request for KMymoney.
Changes
-
> On April 28, 2012, 6:52 a.m., Marko Käning wrote:
> > This looks all sensible to me.
> >
> >
> > And yes, why wouldn't one want to use this approach:
> >
> > > -why are the month names as translatable strings in there, isn't it
> > > enough to call QDate::longMonthName()?
> >
> >
>
>
Every dependency we bring into KMyMoney has a clear set of features and
benefits for the application (libGMP, libofx, aqbanking, etc.). In this
case, I only see a limited value for the developers. And it seems to me,
this could be done the Qt way. Maybe the other way is more clear, but the
only re
Hi Alvaro, all,
I chose to use boost::optional not just because it's convenient, but
mainly because it makes my intentions clear. TransactionMatchFinder
class will either find a matching transaction or not, that's what
boost::optional is for - it either holds an object inside, or it
doesn't. I can
