[kmymoney] [Bug 405808] Unknown property X-KMyMoney-Sepa-Country

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=405808

--- Comment #5 from Christian David  ---
This code part was significantly changed by another developer. So I cannot tell
you if it is required anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 405009] Can't Modify Option if a chose french language

[Christian Theriault]

https://bugs.kde.org/show_bug.cgi?id=405009

--- Comment #6 from Christian Theriault  ---
Thank you is ok now

Find link at:
https://software.opensuse.org/package/mingw64-kmymoney-installer

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 405009] Can't Modify Option if a chose french language

[Christian Theriault]

https://bugs.kde.org/show_bug.cgi?id=405009

--- Comment #5 from Christian Theriault  ---
thank you
I find with google at
https://software.opensuse.org/package/mingw64-kmymoney-installer

windows:mingw:win6
<https://build.opensuse.org/package/show/windows%3Amingw%3Awin64/mingw64-kmymoney%3Amingw64-kmymoney-installer>
  4.8.3


Le mar. 5 mars 2019 à 10:19, Ralf Habacker  a
écrit :

> https://bugs.kde.org/show_bug.cgi?id=405009
>
> --- Comment #4 from Ralf Habacker  ---
>  (In reply to Ralf Habacker from comment #3)
> > I will post an update url.
>
> At https://software.opensuse.org/explore you may search for one of
>
> mingw32-kmymoney-portable
> mingw32-kmymoney-installer
>
> or for the 64bit variant
>
> mingw64-kmymoney-portable
> mingw64-kmymoney-installer
>
> choose version 4.8.3, then click download and unpack with 7zip.
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 405009] New: Can't Modify Option if a chose french language

[Christian Theriault]

https://bugs.kde.org/show_bug.cgi?id=405009

Bug ID: 405009
   Summary: Can't Modify Option if a chose french language
   Product: kmymoney
   Version: 4.8.3
  Platform: MS Windows
OS: MS Windows
Status: REPORTED
  Severity: major
  Priority: NOR
 Component: translation
  Assignee: kmymoney-devel@kde.org
  Reporter: christianipho...@gmail.com
  Target Milestone: ---

SUMMARY
Windows 10 Version try with version 4.8.2 and 4.8.3 ok with 4.8.0

STEPS TO REPRODUCE
1. Settings - KDE Language settings
2. Chose French Luanguages
3. 

OBSERVED RESULT
I Can't Modify Numbers, Money, Calendar and Date & Time Option

No trouble if a chose American English

EXPECTED RESULT

No possibily to choose decimal seperator etc. after Apply the options stay
empty

SOFTWARE/OS VERSIONS
Windows: Windows 10
MacOS: 
Linux/KDE Plasma: 4.14.60
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Future of Alkimia

[Christian David]

Hello Lukasz, Thomas, Jack and Thomas,

I am afraid that this discussion could just end without any decision. So let 
me sum up what we have until now:

1) Alkimia is only used by KMyMoney. So using it as a separate library is not 
useful.

2) For eight years no feature was added that makes alkimia of interested for 
other software developers.

3) Instead of dropping Alkimia we could make it useful (for the first time).

Is that a good representation?

So I recommend: we wait until 23rd of October 2018 (this is in 6 months). If 
there is no new feature¹ then we drop it. Knowingly that the git repository, 
the wiki etc. will still be kept and can be reactivated if needed.

I want to highlight that this does not mean that the ideas behind alkimia are 
bad nor that the work which went into it were senseless! I spent a lot of time 
with alkimia, too!

Btw: the first svn commit to Alkimia was on Sun May 23 13:15:55 2010 (8 years 
- 1 week ago).

Best
Chris

¹ A feature that makes alkimia of real interest to other programs

Am Mittwoch, 4. April 2018, 18:34:28 CEST schrieb Christian David:
> For this reason I recommend to drop alkimia and move AlkValue into KMyMoney
> directly.

[kmymoney] [Bug 393953] Can't print to PDF or printer

[Christian]

https://bugs.kde.org/show_bug.cgi?id=393953

--- Comment #12 from Christian <gen...@moin.fi> ---
Version 5.0.1 showing as 5.0.0 is a known Bug 392372 .

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 393953] Can't print to PDF or printer

[Christian]

https://bugs.kde.org/show_bug.cgi?id=393953

--- Comment #11 from Christian <gen...@moin.fi> ---
I also ran kmymoney from the command line and printed one report to a PDF.
Here's the command-line output:
ca@puolukka ~ $ kmymoney
WebConnect: Try to connect to WebConnect server
WebConnect: Connect to server failed
WebConnect: Running in server mode
Plugins: checkprinting loaded
Plugins: csvexporter loaded
Plugins: csvimporter loaded
Plugins: gncimporter loaded
Plugins: qifexporter loaded
Plugins: qifimporter loaded
Plugins: reconciliation report loaded
Online plugins found 0
Cost center model created with items 0
Payees model created with items 0
reading file
start parsing file
startDocument
reading securities
endDocument
void KReportsView::slotOpenReport(const MyMoneyReport&)   "Income/Expenses by
month, detailed"
Plugins: checkprinting unloaded
Plugins: csvexporter unloaded
Plugins: csvimporter unloaded
Plugins: gncimporter unloaded
Plugins: qifexporter unloaded
Plugins: qifimporter unloaded
Plugins: reconciliation report unloaded

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 393953] Can't print to PDF or printer

[Christian]

https://bugs.kde.org/show_bug.cgi?id=393953

--- Comment #10 from Christian <gen...@moin.fi> ---
Created attachment 112555
  --> https://bugs.kde.org/attachment.cgi?id=112555=edit
emerge --info for Christian's setup

Here's my emerge --info output.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: plugin problem with newly compiled KMM from git master

[Christian Dávid]

Hi Jack,

there is a high chance that KMyMoney is not loading the plugin you compiled but 
one that was shipped with your distribution. This also explains why the 
debugger is not working (it should work without any problems). I had the same 
problem and my (bad) solution was to uninstall the version of KMyMoney of my 
distribution.

Best
Chris

> Jack  hat am 9. Mai 2018 um 00:47 
> geschrieben:
> 
> 
> In trying to track down the printing problem recently filed as a bug,  
> I'm having a problem debugging plugins.  As far as I can tell, printing  
> of reports is handled by KReportsView::slotPrintView() in  
> kmymoney/plugins/views/reports/kreportsview.cpp.  Unfortunately, I  
> can't figure out how to get gdb to set a breakpoint in that file,  
> probably because it is a plugin and not part of the program itself.  If  
> anyone can provide any hints or pointers on suitable instructions, I'd  
> appreciate it.
> 
> One interesting thing, however, is that if I print to file, and  
> ~/print.pdf does not exists, the print simply fails silently.  If that  
> file exists, I do get the prompt asking if I want to overwrite, but  
> even if I say yes, it does not do so.
> 
> I'm also still looking to see if I can find any other problems with  
> printing from other KDE applications, but I haven't found anything so  
> far.
> 
> Jack

[kmymoney] [Bug 393953] Can't print to PDF or printer

[Christian]

https://bugs.kde.org/show_bug.cgi?id=393953

Christian <gen...@moin.fi> changed:

   What|Removed |Added

 CC||gen...@moin.fi

--- Comment #4 from Christian <gen...@moin.fi> ---
I tried it on my Gentoo install, also with kmymoney-5.0.1. Here, "Print to PDF"
created the file /home/ca/print.pdf and its contents correspond to the report
that was on the screen when I clicked on Print.
Next I tried to print a diagram, again using the same PDF file (and saying Yes
to the overwrite question). Its contents were changed, the previous report
disappeared, but the diagram was not included in the PDF file. Instead, the PDF
now shows a one-page document that is blank except for a grey box filling most
of the page.
Last, I opened another report and printed that one to PDF, again overwriting
the same file. It worked and the new report is now in the PDF.
I haven't tried printing to a printer.
For information, my emerge USE flags for the installed kmymoney are:

Installed versions:  5.0.1-r2(5)(18.50.49 06.04.2018)(activities handbook
quotes -addressbook -calendar -debug -hbci -holidays -ofx -test -weboob
PYTHON_TARGETS="python2_7")

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 390411] Sqlite opening broken

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=390411

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 CC|    |christian-da...@web.de

--- Comment #4 from Christian David <christian-da...@web.de> ---
Could this be connected with or caused by bug 341304?

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Future of Alkimia

[Christian David]

Hello Ralf,

Am Donnerstag, 12. April 2018, 17:09:16 CEST schrieb Ralf Habacker:
> Another option would be make it more interesting for other projects by
> adding more stuff into.

Do not get me wrong, I still think the original ideas are very good [1]. 
However, there were no development on features for eight years, why should it 
happen now or in future? Also I think we should think like: there is a 
problem, this should be solved with a library. Not the other way round: we 
want a library, how can we get people to use it?

Best
Chris

[1] https://community.kde.org/Alkimia/Usecases

[kmymoney] [Bug 392755] kmymoney-4.8.1.1 suggestion: Category for realized profit/loss of an investment

[Christian]

https://bugs.kde.org/show_bug.cgi?id=392755

--- Comment #7 from Christian <gen...@moin.fi> ---
See bug 393204 for a related wish for enhancement concerning the overall
profits/losses associated with an equity. The suggestion of the present bug
concerns individual transactions, but there is some overlap to the other bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 393204] Wishlist - Enhancement within Investment Tab

[Christian]

https://bugs.kde.org/show_bug.cgi?id=393204

--- Comment #5 from Christian <gen...@moin.fi> ---
PS: An alternative suggestion for how to present the information (seen from the
"Equity" point of view and not from the "Current balance" point of view used in
my earlier Comment 3):
- A: Sum up the values of all investments into the equity ever (i.e., buy)
- B: Sum up the values of all withdrawals from the equity ever (i.e., sell)
- C: Calculate the current value of the quantity being held (it's already on
the Tab)
- D: Calculate B+C to capture to the total value
- Then compare A (invested money) to D (obtained money plus current value). 
Fees could be added to A if desired.

Maybe this would be better done in a "Report" as it reflects a mixture of the
current holdings and transactions already in the past.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 393204] Wishlist - Enhancement within Investment Tab

[Christian]

https://bugs.kde.org/show_bug.cgi?id=393204

Christian <gen...@moin.fi> changed:

   What|Removed |Added

 CC||gen...@moin.fi

--- Comment #4 from Christian <gen...@moin.fi> ---
Interesting idea. I agree with Jack that the net cost and gain/loss are
characteristics of a transaction - see bug 392755 for a suggestion how to
capture the realized gains and losses.
I understand that Michael Carpino's suggestion here concerns the "gains/losses"
of an investment that are not yet realized, i.e., how does the current value of
the investment compare to the money invested to obtain it. For example, if I
own 30 units of XYZ that I bought for 10 euros each, then the "cost" would be
300 euros. This could be shown on the "Investment tab", so that one may compare
it to the current value (shown in the Value column already). A column for
"gain/loss" in absolute or % terms could be derived from this.

To operationalize this, one would need to know the exact transactions that
constitute the purchasing of the currently held Quantity. E.g., if I buy 10
units of XYZ on 1.1.2017 and another 10 units of XYZ on 1.7.2017, and then sell
10 units on 1.11.2017 - which 10 units do I still own now? Their purchasing
value would be the "investment value". Optionally, the cumulative fees could be
shown here too, although it is again unclear whether e.g., the fees of the
purchase on 1.1.2017 are still relevant in my example.

One could even calculate something like average annual rate of change if the
duration of the holding can be determined.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Future of Alkimia

[Christian David]

Hello Ralf,

Am Donnerstag, 12. April 2018, 17:09:16 CEST schrieb Ralf Habacker:
> Another option would be make it more interesting for other projects by
> adding more stuff into.

Do not get me wrong, I still think the original ideas are very good [1]. 
However, there were no development on features for eight years, why should it 
happen now or in future? Also I think we should think like: there is a 
problem, this should be solved with a library. Not the other way round: we 
want a library, how can we get people to use it?

Best
Chris

[1] https://community.kde.org/Alkimia/Usecases

[kmymoney] [Bug 322926] Having problem resorting data in KMM.

[Christian]

https://bugs.kde.org/show_bug.cgi?id=322926

--- Comment #8 from Christian <gen...@moin.fi> ---
In my view, the balance column should always be available. The balance has to
be calculated in chronological order. That is, for a row with a newer date, the
balance column must refer to the row with the most recent earlier date, and the
amount has to be calculated from that balance and the amount entered on the
current row. It makes no sense to calculate the balance from top to bottom
irrespective of sort order because then one row can show a date and a balance
that does not match.

There is an issue on how to calculate the balance when there are multiple rows
with the same date. I suggest that, here, it makes sense to calculate it from
top to bottom. I.e., here's my suggestion:

1. Sort order can be customized and the rows on the sheet are sorted in that
way.
2. For calculation of the balance only, rows are sorted by
   (a) removing the "Date" sort key from the sort list if present,
   (b) if "Date" is sorted as descending, then reverting the order on each of
the other sort keys,
   (c) making "Date" the first sort key, ascending or descending as specified
in the sort (1),
   (d) then calculating the balance from the first row to the last row (if the
Date key is ascending) or from the last row to the first row (if the Date key
is descending).
   (e) The balance that is obtained in this way is shown in the rows that are
sorted as in (1).

I think we get the correct balances this way. The inversion of the other sort
keys in (2.b) is so that the balance column is as sensible as possible when
reading it in the final order.

Alternatively, we could get rid of the balance column and show the balance on
the separator headers. Then it would make sense (I think) to show the balances
only if the sort order is with Date as the first key. Note that the balance has
to be calculated from oldest to newest even if the sort order is from newest to
oldest.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 361318] Setting reconciliation status fails if multi-selection includes scheduled transactions

[Christian]

https://bugs.kde.org/show_bug.cgi?id=361318

Christian <gen...@moin.fi> changed:

   What|Removed |Added

 CC||gen...@moin.fi

--- Comment #3 from Christian <gen...@moin.fi> ---
I installed KMyMoney version 5.0.1 amd tried to confirm. Here, I can select
multiple transactions including some with future date, and then right-click and
Mark as reconciled or mark as cleared, and everything works as expected. Cannot
confirm bug. Maybe it's been fixed?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 393225] New: Wishlist: Payee-specific setting for whether to autofill with prior transactions

[Christian]

https://bugs.kde.org/show_bug.cgi?id=393225

Bug ID: 393225
   Summary: Wishlist: Payee-specific setting for whether to
autofill with prior transactions
   Product: kmymoney
   Version: 5.0.1
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kmymoney-devel@kde.org
  Reporter: gen...@moin.fi
  Target Milestone: ---

Currently, (depending on the setting in the Settings/Ledger) KMyMoney suggests
prior transactions to autofill a new transaction, after entering the Payee.

I find that, for most Payees, I never use the suggestions and click Cancel, but
for some I always use the suggestion.  It would be nice to have a setting
(ideally on the popup with suggestions, "Never show again for this payee" with
a check-box) to hide the suggestions for some, but not all payees. This setting
could be shown also under Payees, so that one can re-activate the autofill
suggestions.

A second issue with the autofill, unrelated to the above: Under the existing
Settings, there is the option to Autofill when the amount is within x% of a
previous transaction. But the autofill suggestion window pops up immediately
after I enter the Payee, and not after I enter any amount, so I don't
understand how this is supposed to work.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 392755] kmymoney-4.8.1.1 suggestion: Category for realized profit/loss of an investment

[Christian]

https://bugs.kde.org/show_bug.cgi?id=392755

--- Comment #6 from Christian <gen...@moin.fi> ---
The solution suggested by mahueb55 is a good one. It can be implemented in two
steps:
1. Add the possibility to configure a category for "gain/loss" - whether
globally, per investment account, or per security can be discussed.
2. Decide how to calculate the profit/loss automatically and implement that.
(This could be optional or replace a temporary solution of entering this value
manually.)

There is the possibility of entering inconsistent values if they are entered
manually and (2) is not implemented. But to me this doesn't pose a problem as
the current method (which would be equivalent to having a 0 profit/loss always)
seems to be inconsistent in the same way.

Another reason why it would be good to have the realized profit/loss in a
category is that some taxes are calculated on it (e.g., "capital gains tax").

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 392755] New: kmymoney-4.8.1.1 suggestion: Category for realized profit/loss of an investment

[Christian]

https://bugs.kde.org/show_bug.cgi?id=392755

Bug ID: 392755
   Summary: kmymoney-4.8.1.1 suggestion: Category for realized
profit/loss of an investment
   Product: kmymoney
   Version: 4.8.1
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kmymoney-devel@kde.org
  Reporter: gen...@moin.fi
  Target Milestone: ---

Suggestion: When selling an investment, calculate the realized profit or loss
and assign a category to it.

Motivation: It would be nice to have the investment "returns" in a category, so
that they show up in the Income/Expenses views. Also, for the accounting, where
the balance sheet shows the current state of all assets, and the difference
from one year to the next is captured in the categories (Income, Expenses),
there has to be a category where this realized profit/loss is captured,
otherwise the differences in the balance sheet and in the "bottom-line" of the
income-expenses do not match.

Implementation: I think that this realized profit/loss is usually calculated by
tracking the purchasing price of the oldest asset still held.

Example 1:
1.1.2016 Buy 10 shares of XYZ at 5 per share (transaction value 50)
1.1.2017 Buy 5 shares of XYZ at 7 per share (transaction value 35)
1.1.2018 Sell 15 shares of XYZ at 9 per share (transaction value 135)
--> Here, the purchase value was 85, the sales value 135, i.e. a profit of 50.
There should be a category where this is shown as 50.

Example 2:
1.1.2016 Buy 10 shares of XYZ at 5 per share (transaction value 50)
1.1.2017 Buy 5 shares of XYZ at 7 per share (transaction value 35)
1.1.2018 Sell 5 shares of XYZ at 9 per share (transaction value 45)
--> This would be a profit of 20 because those 5 shares were bought 1.1.2016 at
price 5. There should be a category where this is assigned to.
1.3.2018 Sell 10 shares of XYZ at 10 per share (transaction value 100)
--> This would be a profit of 40 because 5 shares were bought 1.1.2016 and 5 on
1.1.2017.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Future of Alkimia

[Christian David]

Hello,

Alkimia was started about eight years ago by the developers of Skrooge, Kraft 
and KMyMoney. Unfortunately it never supported more than AlkValue. As far as I 
know, KMyMoney is the only project left to use alkimia. Skrooge and Kraft are  
not using it anymore and I do not know any other software to use alkimia.

For this reason I recommend to drop alkimia and move AlkValue into KMyMoney 
directly. This reduces the maintenance for developers, packages and users who 
just want to compile KMyMoney on their own. Additionally it reduces possible 
sources of trouble (just remember how much work it was for Ralf to get it 
working with Qt 4 & 5) and we remove a dependency.

What are you thinking about this?

Best
Chris

Re: KMyMoney release creation

[Christian Dávid]

Hi Thomas,

these are good new. Is there a decision regarding [1], yet? Fixing that should 
be easy if the error is known.

Best
Chris

[1] https://phabricator.kde.org/R261:44f846f13d0f7c7cca1178d56492471cb9f5092b


> Thomas Baumgart  hat am 4. Februar 2018 um 16:10 
> geschrieben:
> 
> 
> Hi folks,
> 
> I will now start the tarball creation process. Since I haven't done it in a 
> long time (we all know that) and a few things have changed since then, I 
> don't 
> expect this to be finished very soon. I will let you know once it's done. Who 
> wants to have a preview and testversion before we add it to the kde download 
> servers? Please e-mail me.
> 
> Regards
> 
> Thomas

Re: Error Linking konlinetasks_sepa

[Christian David]

Hi Gary,

could you solve the problem already?

If not: I doubt the issue is caused by the version of CMake you are using (it 
is not way newer than the version I used to create the files and CMake is 
pretty good in backwards compatibility).

Currently I asume this is an issue with automoc or an incorrect 
#include "moc_...". Did you try a full clean and rebuild?

Best
Christian

Am Samstag, 29. Juli 2017, 04:22:13 CET schrieb Gary Duzan:
>I've been trying to get KMyMoney4 working on NetBSD through pkgsrc/wip,
> and have made a fair amount of progress. I have rough packages for
> libalkimia, gwenhywfar, and aqbanking compiling, and now I'm working on
> kmymoney4 itself. It is currently failing to link konlinetasks_sepa.so,
> with multiple definitions from sepaStoragePlugin, one from
> plugins/onlinetasks/sepa/moc_sepastorageplugin.cpp and one from
> plugins/onlinetasks/sepa/konlinetasks_sepa_OBJECTS_autogen/EWIEGA46WW/moc_s
> epastorageplugin.cpp . I've included the full error below. Does this look
> familiar, or do I need to just dive into the cmake stuff? This is with
> 4.8.0 sources.
> 
>Thanks.
> 
>   Gary Duzan
> 
> 
> 
> [ 77%] Linking CXX shared module ../../../../lib/konlinetasks_sepa.so
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_autogen/m
> oc_compilation.cpp.o: In function
> `sepaStoragePlugin::qt_static_metacall(QObject*, QMetaObject::Ca ll, int,
> void**)':
> /usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinetasks/s
> epa/konlinetasks_sepa_OBJECTS_autogen/EWIEGA46WW/moc_sepastorageplugin.cpp:4
> 0: multiple definition of `sepaStoragePlugin::qt_static_metacall(QObject*,
> QMetaObject::Call, int, void**)'
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_automoc.
> cpp.o:/usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinet
> asks/sepa/moc_sepastorageplugin.cpp:40: first defined here
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_autogen/
> moc_compilation.cpp.o: In function `onlineJob::isLocked() const':
> /usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinetasks/
> sepa/konlinetasks_sepa_OBJECTS_autogen/EWIEGA46WW/moc_sepastorageplugin.cpp:
> 62: multiple definition of `sepaStoragePlugin::metaObject() const'
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_automoc.
> cpp.o:/usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinet
> asks/sepa/moc_sepastorageplugin.cpp:62: first defined here
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_autogen/
> moc_compilation.cpp.o: In function `sepaCreditTransferEdit::metaObject()
> const':
> /usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinetasks/
> sepa/konlinetasks_sepa_OBJECTS_autogen/UYX5XTB5RZ/moc_sepacredittransferedit
> .cpp:124: multiple definition of `sepaStoragePlugin::staticMetaObject'
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_automoc.
> cpp.o:/usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinet
> asks/sepa/moc_sepastorageplugin.cpp:40: first defined here
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_autogen/
> moc_compilation.cpp.o: In function `sepaStoragePlugin::qt_metacast(char
> const*)':
> /usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinetasks/
> sepa/konlinetasks_sepa_OBJECTS_autogen/EWIEGA46WW/moc_sepastorageplugin.cpp:
> 66: multiple definition of `sepaStoragePlugin::qt_metacast(char const*)'
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_automoc.
> cpp.o:/usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinet
> asks/sepa/moc_sepastorageplugin.cpp:66: first defined here
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_autogen/
> moc_compilation.cpp.o: In function
> `sepaStoragePlugin::qt_metacall(QMetaObject::Call, int, void**)':
> /usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinetasks/
> sepa/konlinetasks_sepa_OBJECTS_autogen/EWIEGA46WW/moc_sepastorageplugin.cpp:
> 79: multiple definition of
> `sepaStoragePlugin::qt_metacall(QMetaObject::Call, int, void**)'
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_automoc.
> cpp.o:/usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinet
> asks/sepa/moc_sepastorageplugin.cpp:79: first defined here
> CMakeFiles/konlinetasks_sepa_OBJECTS.dir/konlinetasks_sepa_OBJECTS_autogen/
> moc_compilation.cpp.o: In function `onlineJob::sendDate() const':
> /usr/pkgsrc/wip/kmymoney4/work/kmymoney-4.8.0/kmymoney/plugins/onlinetasks/
> sepa/konlinetasks_sepa_OBJECTS_autogen/EWIEGA46WW/moc_sepastorageplugin.cpp:
> 62: multiple definition of `sepaStoragePlugin::staticMetaO

Re: encryption/sqlcipher support (4.8 branch)

[Christian Dávid]

Hi Dieter,

as author of the sqlcipher plugin I can confirm your finding, that it is not 
involved in fedora bug 1423441.

The sqlcipher qt-plugin is only needed if you want to encrypt SQLite database 
files. However, I do not know if anybody ever really used it. It is more a 
proof-of-concept. Btw. the plugin it totally independent from KMyMoney and 
requires Qt and Sqlcipher only.

Best
Christian

> Rex Dieter <rdie...@math.unl.edu> hat am 14. August 2017 um 16:01 geschrieben:
> 
> 
> Rex Dieter wrote:
> 
> > Rex Dieter wrote:
> > 
> >> I've been investigating a feature request for fedora packaging,
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1423441
> >> 
> >> I presumed this was to enable the sqlcipher plugin,
> > 
> > OK, looking closer at sources, this encryption support appears to be
> > unrelated to sqlcipher, more a gpgme issue.  Is this call failing somehow?
> > from  libkgpgfile/kgpgfile.cpp:
> > 
> > bool KGPGFile::GPGAvailable()
> > {
> >   GpgME::initializeLibrary();
> >   bool rc = (GpgME::checkEngine(GpgME::OpenPGP) == 0);
> >   // qDebug("KGPGFile::GPGAvailable returns %d", rc);
> >   return rc;
> > }
> 
> nvm, enabled that qDebug line, and I'm seeing:
> 
> KGPGFile::GPGAvailable returns 1
> 
> Looking more, seems this is also grey if gpg (default?) keys aren't 
> configured ahead of time.  Not ideal UI-wise, but at least I found an 
> explanation.  Sorry for the noise.
> 
> -- Rex
>

Re: Review Request 127678: Register metatypes that are used in Qt Designer files to eliminate warnings.

[Christian David]

> On April 22, 2016, 8:19 vorm., Christian David wrote:
> > Hi Mitch,
> > 
> > according to the [Qt 
> > Docu](http://doc.qt.io/qt-5/qmetatype.html#qRegisterMetaType-1) 
> > ```qRegisterMetaType``` is (only) needed under some circumstances:
> > 
> > To use the type T in QVariant, using Q_DECLARE_METATYPE() is 
> > sufficient. To use the type T in queued signal and slot connections, 
> > qRegisterMetaType() must be called before the first connection is 
> > established.
> > 
> > To prevent complicated issues if we use queued connections ourself in the 
> > future the ```qRegisterMetaType``` should go somewhere else. I think it 
> > should be ```mymoneymoney.cpp``` for ```MyMoneyMoney``` but I am unsure 
> > here.
> 
> Mitch Frazier wrote:
> In terms of logically where it ought to go I don't know, I'm not that 
> familiar with the organization of the code base.  However, in terms of 
> satisfying the requirement that it "must be called before the first 
> connection is established," making it a static variable initializer should be 
> sufficient regardless of where it is placed.  Static initializers are run 
> when the .so is loaded so they'll be executed before any "real" code gets run.
> 
> Christian David wrote:
> In your case they are loaded in another (kind of unrelated) library than 
> the library of the original objects. This violates the concept of enclosed 
> units. To be specific; the ```qRegisterMetaType()``` call should be in the 
> ```kmm_mymoney``` library. To suppress the warnings only they could go in the 
> ```kmymoneywidgets``` library (but not ```kmm_widgets```). Your static 
> initializer trick is cool.
> 
> Thomas Baumgart wrote:
> Ping: Christian / Mitch what is the status on this one? Did you come to a 
> conclusion what to do with the patch?

I recommend to use my recommended relocation of the ´´´qRegisterMetaType()´´´.


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127678/#review94753
---


On April 22, 2016, 5:01 nachm., Mitch Frazier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127678/
> ---
> 
> (Updated April 22, 2016, 5:01 nachm.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Register metatypes to eliminate Qt Desinger warnings.
> 
> Registering metatypes for a type used in a widget eliminates
> the following types of warnings from Qt Designer on start up
> (displayed when designer is started from a console window):
> 
> QMetaProperty::read: Unable to handle unregistered datatype
>   '' for property '::'
> 
> 
> Diffs
> -
> 
>   kmymoney/widgets/kmymoneycurrencyselector.cpp 41be539 
>   kmymoney/widgets/kmymoneyedit.cpp ac79db7 
> 
> Diff: https://git.reviewboard.kde.org/r/127678/diff/
> 
> 
> Testing
> ---
> 
> Tested dialogs that use the data types.
> 
> 
> Thanks,
> 
> Mitch Frazier
> 
>

Re: Review Request 130009: Use qCDebug instead of qDebug

[Christian David]

> On Juni 4, 2017, 11:36 vorm., Christian David wrote:
> > I suggest to discard this review request. Mainly because I do not think 
> > that we will write the long text ```qCDebug(LOG_KMYMONEY)``` in future. 
> > Maybe we can use this for some submodules of KMyMoney in future.

Btw: For what do you need or want this?


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130009/#review103275
---


On März 13, 2017, Mittag, José Arthur Benetasso Villanova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130009/
> ---
> 
> (Updated März 13, 2017, Mittag)
> 
> 
> Review request for KMymoney and José Arthur Benetasso Villanova.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Use qCDebug instead of qDebug
> 
> 
> Diffs
> -
> 
>   kmymoney/CMakeLists.txt 585c7d4 
>   kmymoney/converter/existingtransactionmatchfinder.cpp 7bedd28 
>   kmymoney/converter/mymoneygncreader.cpp 4c6d28c 
>   kmymoney/converter/mymoneyqifreader.cpp 3ad6723 
>   kmymoney/converter/mymoneyqifwriter.cpp da796a3 
>   kmymoney/converter/mymoneystatementreader.cpp 825b490 
>   kmymoney/converter/scheduledtransactionmatchfinder.cpp 4713a2b 
>   kmymoney/converter/tests/converter-test.cpp 3b596ee 
>   kmymoney/converter/transactionmatchfinder.cpp 56e97dd 
>   kmymoney/converter/webpricequote.cpp 15b1467 
>   kmymoney/dialogs/kgeneratesqldlg.cpp 5d20c1d 
>   kmymoney/dialogs/kselectdatabasedlg.cpp c281fc8 
>   kmymoney/kmymoney.h dd37972 
>   kmymoney/kmymoney.cpp 674f251 
>   kmymoney/kmymoneyutils.cpp 0492578 
>   kmymoney/logging.h PRE-CREATION 
>   kmymoney/logging.cpp PRE-CREATION 
>   kmymoney/main.cpp 77d68a7 
>   kmymoney/models/accountsmodel.cpp 12aac8d 
>   kmymoney/models/costcentermodel.cpp ac2d671 
>   kmymoney/models/ledgermodel.cpp 47e7b06 
>   kmymoney/models/modeltest.cpp 225e5de 
>   kmymoney/models/payeesmodel.cpp 35ff045 
>   kmymoney/mymoney/CMakeLists.txt 33b6177 
>   kmymoney/mymoney/mymoneyfile.h 2494af3 
>   kmymoney/mymoney/mymoneyfile.cpp d39a1d6 
>   kmymoney/mymoney/mymoneyforecast.cpp b286a85 
>   kmymoney/mymoney/onlinejobadministration.cpp d5f44f6 
>   kmymoney/mymoney/storage/mymoneystoragesql.cpp 4a68175 
>   kmymoney/mymoney/storage/tests/mymoneydatabasemgr-test.cpp dbaf6d0 
>   kmymoney/mymoney/tests/mymoneymoney-test.cpp ef1dd26 
>   kmymoney/mymoney/tests/mymoneyschedule-test.cpp 5c911fe 
>   kmymoney/mymoney/tests/mymoneytransaction-test.cpp f6d52c6 
>   kmymoney/plugins/CMakeLists.txt 6b235fb 
>   kmymoney/plugins/csvexport/CMakeLists.txt 454d7d2 
>   kmymoney/plugins/csvexport/csvwriter.cpp 83365bb 
>   kmymoney/plugins/csvimport/csvwizard.cpp e9ca8a6 
>   kmymoney/plugins/icalendarexport/CMakeLists.txt e30245f 
>   kmymoney/plugins/icalendarexport/schedulestoicalendar.cpp ed14916 
>   kmymoney/plugins/kbanking/mymoneybanking.cpp 3e2f25b 
>   kmymoney/plugins/ofximport/dialogs/CMakeLists.txt b913db8 
>   kmymoney/plugins/ofximport/dialogs/kofxdirectconnectdlg.cpp 2ddbb39 
>   kmymoney/plugins/ofximport/dialogs/mymoneyofxconnector.cpp cff2ed9 
>   kmymoney/plugins/onlinejobpluginmockup/onlinejobpluginmockup.cpp 83be16e 
>   kmymoney/plugins/reconciliationreport/CMakeLists.txt b28dc02 
>   kmymoney/plugins/reconciliationreport/reconciliationreport.cpp ee2d42f 
>   kmymoney/reports/kreportchartview.cpp d1f0c51 
>   kmymoney/reports/pivottable.cpp 833dc45 
>   kmymoney/reports/querytable.cpp 4d5a843 
>   kmymoney/reports/reporttable.cpp 1acec56 
>   kmymoney/reports/tests/reportstestcommon.cpp f64d3b6 
>   kmymoney/tests/kmymoneyutils-test.h 3faac41 
>   kmymoney/views/kforecastview.cpp 13c8b1a 
>   kmymoney/views/kmymoneyview.cpp 91750fa 
>   kmymoney/views/konlinejoboutbox.cpp 0708346 
>   kmymoney/views/kpayeesview.cpp fbe6fd0 
>   kmymoney/views/kreportsview.cpp a98d5b8 
>   kmymoney/views/ktagsview.cpp f361a4b 
>   kmymoney/views/ledgerdelegate.cpp 7274966 
>   kmymoney/views/ledgerview.cpp 8807d40 
>   kmymoney/views/newspliteditor.cpp 707117a 
>   kmymoney/views/newtransactioneditor.cpp b7f070d 
>   kmymoney/views/simpleledgerview.cpp 6793fdf 
>   kmymoney/views/splitdelegate.cpp 510d55f 
>   kmymoney/views/splitdialog.cpp becdfcf 
>   kmymoney/widgets/CMakeLists.txt 7560682 
>   kmymoney/widgets/kmymoneymvccombo.cpp 29e378f 
>   kmymoney/widgets/transaction.cpp 4061ae2 
> 
> Diff: https://git.reviewboard.kde.org/r/130009/diff/
> 
> 
> Testing
> ---
> 
> For now just compiled
> 
> 
> Thanks,
> 
> José Arthur Benetasso Villanova
> 
>

Re: Review Request 130009: Use qCDebug instead of qDebug

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130009/#review103275
---



I suggest to discard this review request. Mainly because I do not think that we 
will write the long text ```qCDebug(LOG_KMYMONEY)``` in future. Maybe we can 
use this for some submodules of KMyMoney in future.

- Christian David


On März 13, 2017, Mittag, José Arthur Benetasso Villanova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130009/
> ---
> 
> (Updated März 13, 2017, Mittag)
> 
> 
> Review request for KMymoney and José Arthur Benetasso Villanova.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Use qCDebug instead of qDebug
> 
> 
> Diffs
> -
> 
>   kmymoney/CMakeLists.txt 585c7d4 
>   kmymoney/converter/existingtransactionmatchfinder.cpp 7bedd28 
>   kmymoney/converter/mymoneygncreader.cpp 4c6d28c 
>   kmymoney/converter/mymoneyqifreader.cpp 3ad6723 
>   kmymoney/converter/mymoneyqifwriter.cpp da796a3 
>   kmymoney/converter/mymoneystatementreader.cpp 825b490 
>   kmymoney/converter/scheduledtransactionmatchfinder.cpp 4713a2b 
>   kmymoney/converter/tests/converter-test.cpp 3b596ee 
>   kmymoney/converter/transactionmatchfinder.cpp 56e97dd 
>   kmymoney/converter/webpricequote.cpp 15b1467 
>   kmymoney/dialogs/kgeneratesqldlg.cpp 5d20c1d 
>   kmymoney/dialogs/kselectdatabasedlg.cpp c281fc8 
>   kmymoney/kmymoney.h dd37972 
>   kmymoney/kmymoney.cpp 674f251 
>   kmymoney/kmymoneyutils.cpp 0492578 
>   kmymoney/logging.h PRE-CREATION 
>   kmymoney/logging.cpp PRE-CREATION 
>   kmymoney/main.cpp 77d68a7 
>   kmymoney/models/accountsmodel.cpp 12aac8d 
>   kmymoney/models/costcentermodel.cpp ac2d671 
>   kmymoney/models/ledgermodel.cpp 47e7b06 
>   kmymoney/models/modeltest.cpp 225e5de 
>   kmymoney/models/payeesmodel.cpp 35ff045 
>   kmymoney/mymoney/CMakeLists.txt 33b6177 
>   kmymoney/mymoney/mymoneyfile.h 2494af3 
>   kmymoney/mymoney/mymoneyfile.cpp d39a1d6 
>   kmymoney/mymoney/mymoneyforecast.cpp b286a85 
>   kmymoney/mymoney/onlinejobadministration.cpp d5f44f6 
>   kmymoney/mymoney/storage/mymoneystoragesql.cpp 4a68175 
>   kmymoney/mymoney/storage/tests/mymoneydatabasemgr-test.cpp dbaf6d0 
>   kmymoney/mymoney/tests/mymoneymoney-test.cpp ef1dd26 
>   kmymoney/mymoney/tests/mymoneyschedule-test.cpp 5c911fe 
>   kmymoney/mymoney/tests/mymoneytransaction-test.cpp f6d52c6 
>   kmymoney/plugins/CMakeLists.txt 6b235fb 
>   kmymoney/plugins/csvexport/CMakeLists.txt 454d7d2 
>   kmymoney/plugins/csvexport/csvwriter.cpp 83365bb 
>   kmymoney/plugins/csvimport/csvwizard.cpp e9ca8a6 
>   kmymoney/plugins/icalendarexport/CMakeLists.txt e30245f 
>   kmymoney/plugins/icalendarexport/schedulestoicalendar.cpp ed14916 
>   kmymoney/plugins/kbanking/mymoneybanking.cpp 3e2f25b 
>   kmymoney/plugins/ofximport/dialogs/CMakeLists.txt b913db8 
>   kmymoney/plugins/ofximport/dialogs/kofxdirectconnectdlg.cpp 2ddbb39 
>   kmymoney/plugins/ofximport/dialogs/mymoneyofxconnector.cpp cff2ed9 
>   kmymoney/plugins/onlinejobpluginmockup/onlinejobpluginmockup.cpp 83be16e 
>   kmymoney/plugins/reconciliationreport/CMakeLists.txt b28dc02 
>   kmymoney/plugins/reconciliationreport/reconciliationreport.cpp ee2d42f 
>   kmymoney/reports/kreportchartview.cpp d1f0c51 
>   kmymoney/reports/pivottable.cpp 833dc45 
>   kmymoney/reports/querytable.cpp 4d5a843 
>   kmymoney/reports/reporttable.cpp 1acec56 
>   kmymoney/reports/tests/reportstestcommon.cpp f64d3b6 
>   kmymoney/tests/kmymoneyutils-test.h 3faac41 
>   kmymoney/views/kforecastview.cpp 13c8b1a 
>   kmymoney/views/kmymoneyview.cpp 91750fa 
>   kmymoney/views/konlinejoboutbox.cpp 0708346 
>   kmymoney/views/kpayeesview.cpp fbe6fd0 
>   kmymoney/views/kreportsview.cpp a98d5b8 
>   kmymoney/views/ktagsview.cpp f361a4b 
>   kmymoney/views/ledgerdelegate.cpp 7274966 
>   kmymoney/views/ledgerview.cpp 8807d40 
>   kmymoney/views/newspliteditor.cpp 707117a 
>   kmymoney/views/newtransactioneditor.cpp b7f070d 
>   kmymoney/views/simpleledgerview.cpp 6793fdf 
>   kmymoney/views/splitdelegate.cpp 510d55f 
>   kmymoney/views/splitdialog.cpp becdfcf 
>   kmymoney/widgets/CMakeLists.txt 7560682 
>   kmymoney/widgets/kmymoneymvccombo.cpp 29e378f 
>   kmymoney/widgets/transaction.cpp 4061ae2 
> 
> Diff: https://git.reviewboard.kde.org/r/130009/diff/
> 
> 
> Testing
> ---
> 
> For now just compiled
> 
> 
> Thanks,
> 
> José Arthur Benetasso Villanova
> 
>

Re: Review Request 130143: Add support for dedicated opening balance account.

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130143/#review103274
---



Here are some things that came to my mind while reading through this review 
request. Unfortunatly I cannot try the patch because I cannot compile the 4.8 
branch.

What happens if the user creates a new account (no opening balances account) 
and enters a opening balance and there is no opening balances account, yet? Is 
a opening balance account created (silently)? The user can rename it later then 
(less user interaction, so this is my preferred behavior).

What if the user creates a opening balances account with a opening balance?


kmymoney/converter/mymoneytemplate.cpp (line 416)
<https://git.reviewboard.kde.org/r/130143/#comment68695>

I think setting a value is not needed. Also someone who only reads the XML 
file could think setting ```value="0"``` could deactivate the flag. Then it 
would be ``.



kmymoney/dialogs/knewaccountdlg.cpp (line 239)
<https://git.reviewboard.kde.org/r/130143/#comment68700>

This could confuse the user. Because he selected his new account to become 
an opening balances account but this option is silently ignored.

To solve this the checkbox to make an account an opening balances account 
could be disabled and a notice or label inform the user why.



kmymoney/dialogs/knewaccountdlg.cpp (line 243)
<https://git.reviewboard.kde.org/r/130143/#comment68699>

```transactionList.isEmpty()``` is faster



kmymoney/mymoney/mymoneyfile.cpp (line 1104)
<https://git.reviewboard.kde.org/r/130143/#comment68697>

The RegExp could be replaced by ```QString::startsWith()```

http://doc.qt.io/qt-5/qstring.html#startsWith



kmymoney/mymoney/mymoneyfile.cpp (line 1107)
<https://git.reviewboard.kde.org/r/130143/#comment68698>

I know you did not write but I see it now: The ```if```s could be combinde 
with ```&&```? Also ```(*it).foobar()``` is ```it->foobar()```.


- Christian David


On Mai 30, 2017, 9:45 vorm., Ralf Habacker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130143/
> ---
> 
> (Updated Mai 30, 2017, 9:45 vorm.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 370290
> http://bugs.kde.org/show_bug.cgi?id=370290
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> This patch introduce a feature to specify a dedicated account
> to be used as opening balance account instead of using an account
> with a predefined name which may be language specific.
> 
> The "opening balance account" flag could be set in the account
> editor if no other account contains this flag. Also changing
> the state of the flag is only possible if no transactions are
> assigned to the account having this flag.
> 
> On creating a new kmymoney file the "opening balance account"
> flag is imported from a related template account flag if specified
> in the following form
> 
> 
>
> 
> 
> If specified the template admin needs to make sure that only one
> template account has this flag set.
> 
> Exporting the current kmymoney file to an account template exports
> this flag too.
> 
> BUG:370290
> 
> 
> Diffs
> -
> 
>   kmymoney/converter/mymoneytemplate.cpp 
> 25a343e3fbdd9409ebdbd814bc08122c151a09d9 
>   kmymoney/dialogs/knewaccountdlg.cpp 
> dfe2967174bf323d9eda4983fd545d0930a9ec43 
>   kmymoney/dialogs/knewaccountdlgdecl.ui 
> bee638d2b4f73bc8496c86bbf606bfaa5fa4c913 
>   kmymoney/mymoney/mymoneyfile.cpp 692014b21ec8bff4e4c3f3f240d377cd7b9697b3 
>   kmymoney/mymoney/storage/mymoneystorageanon.cpp 
> b6d0dc6a7b499aa45498cb76bef836731ff618d4 
>   kmymoney/reports/objectinfotable.cpp 
> 584a9a378d37d51766e551d8e6b6baffe4fb397d 
>   kmymoney/reports/reportstestcommon.h 
> 22000165dff793c5d7281072f702e0ca3c40f882 
>   kmymoney/reports/reportstestcommon.cpp 
> 40b103ca965e0a1973b6fd0a351ddb976aa10471 
> 
> Diff: https://git.reviewboard.kde.org/r/130143/diff/
> 
> 
> Testing
> ---
> 
> - compiled
> - set/unset "opening balance account" flag in account editor for a given 
> account and save/load kmymoney file -> state is persistent
> - checked if it is possible to set "opening balance account" flag in an 
> additional account -> check box is not visible on editing the second account
> - checked if it is possible to change "opening balance account" flag if 
> transactions are assigned to the opening balance account -> check box is 
> disabled
> 
> Note: I choosed the flag name as to be 'OpeningBalanceAccount' in the 
> template file and kmymoney file to have the same name.
> 
> 
> Thanks,
> 
> Ralf Habacker
> 
>

Severe bug in reports in master branch

[Christian David]

Hello,

I just noticed a severe bug in the reports which is probably not very old. In 
a tax report I ordered the transactions by category. However, in a category a 
split is shown which has a different category but another split of the 
transaction is in that category.

Has somebody change something is this area?

Best
Chris

Re: Review Request 130143: Add support for dedicated opening balance account.

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130143/#review103259
---



Without reading the details: I think we should put all effort into the master 
branch. The 4.8 branch should be for bug-fixes only because there is no chance 
that we can keep support for Qt 4/kdelibs 4.

- Christian David


On Mai 30, 2017, 9:45 vorm., Ralf Habacker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130143/
> ---
> 
> (Updated Mai 30, 2017, 9:45 vorm.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 370290
> http://bugs.kde.org/show_bug.cgi?id=370290
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> This patch introduce a feature to specify a dedicated account
> to be used as opening balance account instead of using an account
> with a predefined name which may be language specific.
> 
> The "opening balance account" flag could be set in the account
> editor if no other account contains this flag. Also changing
> the state of the flag is only possible if no transactions are
> assigned to the account having this flag.
> 
> On creating a new kmymoney file the "opening balance account"
> flag is imported from a related template account flag if specified
> in the following form
> 
> 
>
> 
> 
> If specified the template admin needs to make sure that only one
> template account has this flag set.
> 
> Exporting the current kmymoney file to an account template exports
> this flag too.
> 
> BUG:370290
> 
> 
> Diffs
> -
> 
>   kmymoney/converter/mymoneytemplate.cpp 
> 25a343e3fbdd9409ebdbd814bc08122c151a09d9 
>   kmymoney/dialogs/knewaccountdlg.cpp 
> dfe2967174bf323d9eda4983fd545d0930a9ec43 
>   kmymoney/dialogs/knewaccountdlgdecl.ui 
> bee638d2b4f73bc8496c86bbf606bfaa5fa4c913 
>   kmymoney/mymoney/mymoneyfile.cpp 692014b21ec8bff4e4c3f3f240d377cd7b9697b3 
>   kmymoney/mymoney/storage/mymoneystorageanon.cpp 
> b6d0dc6a7b499aa45498cb76bef836731ff618d4 
>   kmymoney/reports/objectinfotable.cpp 
> 584a9a378d37d51766e551d8e6b6baffe4fb397d 
>   kmymoney/reports/reportstestcommon.h 
> 22000165dff793c5d7281072f702e0ca3c40f882 
>   kmymoney/reports/reportstestcommon.cpp 
> 40b103ca965e0a1973b6fd0a351ddb976aa10471 
> 
> Diff: https://git.reviewboard.kde.org/r/130143/diff/
> 
> 
> Testing
> ---
> 
> - compiled
> - set/unset "opening balance account" flag in account editor for a given 
> account and save/load kmymoney file -> state is persistent
> - checked if it is possible to set "opening balance account" flag in an 
> additional account -> check box is not visible on editing the second account
> - checked if it is possible to change "opening balance account" flag if 
> transactions are assigned to the opening balance account -> check box is 
> disabled
> 
> Note: I choosed the flag name as to be 'OpeningBalanceAccount' in the 
> template file and kmymoney file to have the same name.
> 
> 
> Thanks,
> 
> Ralf Habacker
> 
>

Re: Review Request 130135: Removed national credit transfers

[Christian David (c.david)]

Hello Andreas,

I noticed that build.kde.org fails since this review request was checked in 
[1]. Do you know why? Or can you even fix it (I cannot compile the 4.8 branch)? 
If not, we can just revert the commit. This change cleans our codebase but 
does not change anything for the user (and the branch 4.8 is at end of 
lifetime).

Best,
Christian


[1] https://build.kde.org/job/kmymoney%204.8%20latest-qt4/89/

On Dienstag, 23. Mai 2017 20:16:21 CEST Andreas Sturmlechner wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130135/
> ---
> 
> (Updated May 23, 2017, 6:16 p.m.)
> 
> 
> Status
> --
> 
> This change has been marked as submitted.
> 
> 
> Review request for KMymoney.
> 
> 
> Changes
> ---
> 
> Submitted with commit c78183f18201b16436008ea4306a974f180141d7 by Andreas
> Sturmlechner on behalf of Christian Dávid to branch 4.8.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> They are not supported by the banks anymore. So they can be removed.
> 
> Unfortunately they contained the only example for a task converter.
> Due to the removed plugin the CMakeLists.txt for sepa could be
> simplified.
> 
> Cherry-picked from d514e650
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/kbanking/aqbankingkmmoperators.h
> a314cd7218118cd695ade0d2344fbb450c698b16
> kmymoney/plugins/kbanking/aqbankingkmmoperators.cpp
> 6c2b5d8a9963c0506c52d2e105fa2443f8350a52
> kmymoney/plugins/kbanking/mymoneybanking.h
> c2559ae73aa5ae5c5480ffac8512d6936a94
> kmymoney/plugins/kbanking/mymoneybanking.cpp
> d8c4a5711548ef5b0f29e228100b35d2d675f238
> kmymoney/plugins/kbanking/tasksettings/credittransfersettingsbase.h
> 28d55a06f1e4446bd1840e8be368533824b6e5d1
> kmymoney/plugins/onlinetasks/CMakeLists.txt
> 7be531376bdf24bd415a9af32812b3a7c47a07b6
> kmymoney/plugins/onlinetasks/national/CMakeLists.txt
> d3e7c44f937d001fed67dcb4b58ba14f293ea774
> kmymoney/plugins/onlinetasks/national/converter/CMakeLists.txt
> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
> kmymoney/plugins/onlinetasks/national/converter/taskconvertergermantosepa.h
> 7653c231fd4d142956a39ac47307f43998cc1344
> kmymoney/plugins/onlinetasks/national/converter/taskconvertergermantosepa.c
> pp d10b3933271235186fe81cceea0cdb2cd1b30d02
> kmymoney/plugins/onlinetasks/national/converter/taskconvertersepatogerman.h
> 900f8d8025ba88f3c2d8fe90bcb9b873dc2897c5
> kmymoney/plugins/onlinetasks/national/converter/taskconvertersepatogerman.c
> pp a7aae64d153a6af9f21586f97fca27865df76b77
> kmymoney/plugins/onlinetasks/national/kmymoney-nationalorders.desktop.in
> af817eed71f4f3aa6f444d3064b2b612824660f1
> kmymoney/plugins/onlinetasks/national/kmymoney-nationalordersui.desktop.in
> f548a33df084cd08d39cdc99356025fbf7052f3b
> kmymoney/plugins/onlinetasks/national/kmymoney-nationalstorageplugin.deskto
> p.in 86db1b08b116ecdab174025faef107a52ae93239
> kmymoney/plugins/onlinetasks/national/nationalonlinetasksloader.h
> 44157e412b27b0f759d2607ebea65d663eced0da
> kmymoney/plugins/onlinetasks/national/nationalonlinetasksloader.cpp
> 4a0c9e7586646c162021e66e5146912fc335c151
> kmymoney/plugins/onlinetasks/national/nationalstorageplugin.h
> c61054b3e892838318e60302ed90ca37c5345eac
> kmymoney/plugins/onlinetasks/national/nationalstorageplugin.cpp
> 5464fb94495b4ecbf0d73a498e9b4badccc6aa94
> kmymoney/plugins/onlinetasks/national/tasks/germanonlinetransfer.h
> 660b4aa481696b58245e3b638a7827e7cb4d23b0
> kmymoney/plugins/onlinetasks/national/tasks/germanonlinetransferimpl.h
> 0b9745574ecdfd17a168ccad5543a8883e92225e
> kmymoney/plugins/onlinetasks/national/tasks/germanonlinetransferimpl.cpp
> a7b4421f2ea0403f4aaf187d39e3c22ae5b19e93
> kmymoney/plugins/onlinetasks/national/tests/CMakeLists.txt
> e606d2d2cbec0c4cc1418f6b23aab20392606da8
> kmymoney/plugins/onlinetasks/national/tests/germanonlinetransfertest.h
> 9c2ca335b7454ec745fa70b56e0b4e3780f0740a
> kmymoney/plugins/onlinetasks/national/tests/germanonlinetransfertest.cpp
> 63834e7952b15fc4f43b0dac40a7d612ea5b97c0
> kmymoney/plugins/onlinetasks/national/ui/germancredittransferedit.h
> aa07cdaa7fcb315cddd6b0ec91090c039d661570
> kmymoney/plugins/onlinetasks/national/ui/germancredittransferedit.cpp
> 8e0da0815e6938cd8b7086e2d955e6de0d452fd9
> kmymoney/plugins/onlinetasks/national/ui/germancredittransferedit.ui
> 5c0b7ff818d95482e10a1d3b052b25ed275849d3
> kmymoney/plugins/onlinetasks/sepa/CMakeLists.txt
> 3c2d9db16c1e3ee3a44f21e008bb1ef884cbb8fb
> 
> Diff: https://git.reviewboard.kde.org/r/130135/diff/
> 
> 
> Testing
> ---
> 
> Successfully builds again with the patch (there was a moc error after
> upgrade to boost-1.63).

Re: Review Request 130135: Removed national credit transfers

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130135/#review103231
---


Ship it!




Ship It!

- Christian David


On Mai 18, 2017, 9:45 nachm., Andreas Sturmlechner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130135/
> ---
> 
> (Updated Mai 18, 2017, 9:45 nachm.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> They are not supported by the banks anymore. So they can be removed.
> 
> Unfortunately they contained the only example for a task converter.
> Due to the removed plugin the CMakeLists.txt for sepa could be
> simplified.
> 
> Cherry-picked from d514e650
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/kbanking/aqbankingkmmoperators.h 
> a314cd7218118cd695ade0d2344fbb450c698b16 
>   kmymoney/plugins/kbanking/aqbankingkmmoperators.cpp 
> 6c2b5d8a9963c0506c52d2e105fa2443f8350a52 
>   kmymoney/plugins/kbanking/mymoneybanking.h 
> c2559ae73aa5ae5c5480ffac8512d6936a94 
>   kmymoney/plugins/kbanking/mymoneybanking.cpp 
> d8c4a5711548ef5b0f29e228100b35d2d675f238 
>   kmymoney/plugins/kbanking/tasksettings/credittransfersettingsbase.h 
> 28d55a06f1e4446bd1840e8be368533824b6e5d1 
>   kmymoney/plugins/onlinetasks/CMakeLists.txt 
> 7be531376bdf24bd415a9af32812b3a7c47a07b6 
>   kmymoney/plugins/onlinetasks/national/CMakeLists.txt 
> d3e7c44f937d001fed67dcb4b58ba14f293ea774 
>   kmymoney/plugins/onlinetasks/national/converter/CMakeLists.txt 
> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 
>   kmymoney/plugins/onlinetasks/national/converter/taskconvertergermantosepa.h 
> 7653c231fd4d142956a39ac47307f43998cc1344 
>   
> kmymoney/plugins/onlinetasks/national/converter/taskconvertergermantosepa.cpp 
> d10b3933271235186fe81cceea0cdb2cd1b30d02 
>   kmymoney/plugins/onlinetasks/national/converter/taskconvertersepatogerman.h 
> 900f8d8025ba88f3c2d8fe90bcb9b873dc2897c5 
>   
> kmymoney/plugins/onlinetasks/national/converter/taskconvertersepatogerman.cpp 
> a7aae64d153a6af9f21586f97fca27865df76b77 
>   kmymoney/plugins/onlinetasks/national/kmymoney-nationalorders.desktop.in 
> af817eed71f4f3aa6f444d3064b2b612824660f1 
>   kmymoney/plugins/onlinetasks/national/kmymoney-nationalordersui.desktop.in 
> f548a33df084cd08d39cdc99356025fbf7052f3b 
>   
> kmymoney/plugins/onlinetasks/national/kmymoney-nationalstorageplugin.desktop.in
>  86db1b08b116ecdab174025faef107a52ae93239 
>   kmymoney/plugins/onlinetasks/national/nationalonlinetasksloader.h 
> 44157e412b27b0f759d2607ebea65d663eced0da 
>   kmymoney/plugins/onlinetasks/national/nationalonlinetasksloader.cpp 
> 4a0c9e7586646c162021e66e5146912fc335c151 
>   kmymoney/plugins/onlinetasks/national/nationalstorageplugin.h 
> c61054b3e892838318e60302ed90ca37c5345eac 
>   kmymoney/plugins/onlinetasks/national/nationalstorageplugin.cpp 
> 5464fb94495b4ecbf0d73a498e9b4badccc6aa94 
>   kmymoney/plugins/onlinetasks/national/tasks/germanonlinetransfer.h 
> 660b4aa481696b58245e3b638a7827e7cb4d23b0 
>   kmymoney/plugins/onlinetasks/national/tasks/germanonlinetransferimpl.h 
> 0b9745574ecdfd17a168ccad5543a8883e92225e 
>   kmymoney/plugins/onlinetasks/national/tasks/germanonlinetransferimpl.cpp 
> a7b4421f2ea0403f4aaf187d39e3c22ae5b19e93 
>   kmymoney/plugins/onlinetasks/national/tests/CMakeLists.txt 
> e606d2d2cbec0c4cc1418f6b23aab20392606da8 
>   kmymoney/plugins/onlinetasks/national/tests/germanonlinetransfertest.h 
> 9c2ca335b7454ec745fa70b56e0b4e3780f0740a 
>   kmymoney/plugins/onlinetasks/national/tests/germanonlinetransfertest.cpp 
> 63834e7952b15fc4f43b0dac40a7d612ea5b97c0 
>   kmymoney/plugins/onlinetasks/national/ui/germancredittransferedit.h 
> aa07cdaa7fcb315cddd6b0ec91090c039d661570 
>   kmymoney/plugins/onlinetasks/national/ui/germancredittransferedit.cpp 
> 8e0da0815e6938cd8b7086e2d955e6de0d452fd9 
>   kmymoney/plugins/onlinetasks/national/ui/germancredittransferedit.ui 
> 5c0b7ff818d95482e10a1d3b052b25ed275849d3 
>   kmymoney/plugins/onlinetasks/sepa/CMakeLists.txt 
> 3c2d9db16c1e3ee3a44f21e008bb1ef884cbb8fb 
> 
> Diff: https://git.reviewboard.kde.org/r/130135/diff/
> 
> 
> Testing
> ---
> 
> Successfully builds again with the patch (there was a moc error after upgrade 
> to boost-1.63).
> 
> 
> Thanks,
> 
> Andreas Sturmlechner
> 
>

[kmymoney4] [Bug 249844] wrong memo field after duplicating and editing transaction

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=249844

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

   Version Fixed In|5.0 |4.8.1

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 378379] Segfault if a Report is deleted from reports menu whilst it is open in a tab.

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=378379

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

   Version Fixed In|5.0 |4.8.1

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 379169] installed mymoneyaccount.h references non-existent payeeidentifier/ headers

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=379169

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 CC|    |christian-da...@web.de
   Assignee|kmymoney-devel@kde.org  |christian-da...@web.de

--- Comment #2 from Christian David <christian-da...@web.de> ---
Hi Rex,

do you need this bug to be fixed in 4.8? I will definitely fix it for 5.x soon.

Greetings
Christian

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Openning of Databases fails

[Christian Dávid]

Hi Thomas,

without further investigating, I asume that the INSERT INTO is executed before 
the update was done. Due to the error the update will never be executed.

Greetings
Christian

> Thomas Baumgart <t...@net-bembel.de> hat am 4. Dezember 2016 um 10:01 
> geschrieben:
> 
> 
> Hi,
> 
> your remark about the backend is also my opinion (gut feeling based).
> 
> The problem you encounter should not happen as I added logic to add the 
> column 
> to the DB once you open an older version. Why does this not get executed?
> 
> Thomas
> 
> 
> On Saturday 03 December 2016 21:23:29 Christian David wrote:
> 
> > Hello,
> > 
> > I cannot open my old databases anymore. The query which causes the problem
> > is attached. Note that there are more colums in INSERT INTO than in the
> > SELECT (the costCenterId) — which will obviously fail.
> > 
> > We really need a new strategy for the database backend, the current state is
> > not tenable.
> > 
> > Greetings
> > Christian
> > 
> > 
> > Driver = QSQLITE, Host = localhost, User = xxx, Database = xxx/kmymoney-
> > testfiles/tset.sqlite
> > Driver Error:
> > Database Error No -1:
> > Text:
> > Error type 0
> > Executed: INSERT INTO kmmSplits (transactionId, txType, splitId, payeeId,
> > reconcileDate, action, reconcileFlag, value, valueFormatted, shares,
> > sharesFormatted, price, priceFormatted, memo, accountId, costCenterId,
> > checkNumber, postDate, bankId) SELECT transactionId, txType, splitId,
> > payeeId, reconcileDate, action, reconcileFlag, value, valueFormatted,
> > shares, sharesFormatted, price, priceFormatted, memo, accountId,
> > checkNumber, postDate, bankId FROM kmmtmpSplits;
> > Query error No -1: No query Unable to fetch row
> > Error type 1
> > void MyMoneyStorageSql::cancelCommitUnit(const QString&) - bool
> > MyMoneyStorageSql::alterTable(const MyMoneyDbTable&, int) s/be int
> > MyMoneyStorageSql::upgradeToV9()
> > terminate called after throwing an instance of 'MyMoneyException'
> -- 
> 
> Regards
> 
> Thomas Baumgart
> 
> GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
> -
> A: Because it destroys the flow of the conversation
> Q: Why is top-posting bad?
> A: Top-posting
> Q: What is the most annoying thing in e-mail?
> -

Re: Review Request 129393: Use Qt's plugin system instead of KService

[Christian David]

> On Dez. 25, 2016, 1:37 nachm., Łukasz Wojniłowicz wrote:
> > After this change, CSV Importer plugin isn't displayed in File->Import 
> > menu, even after steps suggested in following post
> > http://kmymoney-devel.kde.narkive.com/hSaamIlT/plugins-path-in-master-branch
> > So please add making this working again to your TODO list.

Hi ?ukasz,

are the other plugins shown? Unfortunatly it will take a week (or two) before I 
can have a look on this issue. However, I am quite sure I checked the 
import/export plugins before I send this patch. Let me revaluate that…

Greetings
Christian


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129393/#review101572
---


On Nov. 26, 2016, 4:12 nachm., Christian David wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129393/
> ---
> 
> (Updated Nov. 26, 2016, 4:12 nachm.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Hi,
> 
> this is my long overdue change on the plugin system. It actually started in 
> Randa.
> 
> Sorry for such a long review request! I think it is ready for publishing, I 
> made this review request only to give everybody a chance to ask questions :)
> 
> 
> Commit 1
> 
> 
> This is a major change. Instead of a KPluginFactory based plugin
> loading, Qt's plugin system is used. The docu was adopeted to reflect
> this.
> 
> Commit 2
> 
> 
> The plugins for onlineTasks are now loaded with QPluginLoader on demand.
> The necessary information is encoded in Qt's json plugin header.
> 
> Commit 3
> 
> 
> Moved plugin loader out of kmm_plugin and put it into the executable
> 
> The plugin shared library is for plugins now and does not include the
> loading of plugins (which was kind of wired). All loading operations of
> standard plugins is done in KMyMoneyApp now.
> 
> Therefor the interface system for plugins needed do be reworked to
> great degree. Some overly complex operations were replaced by simpler
> ones. All plugins were adopted to that. Also it is more type safe now.
> 
> Now the user configuration which plugins should be loaded or not is
> respected (standard plugins only).
> 
> An old bug was fixed: If the configuration in the plugin settings
> changed the plugins are loaded/unloaded after the user accepts the
> dialog (perviously this was done when the checkbox was clicked).
> 
> Todos
> =
> 
> The new system is still not finished. However, it is a great step in
> the right direction. An uncomplete list of FIXMEs (or bugs?):
> 
> 1. pluginloader.{h,cpp} are gui only now and should be merged into the
> settings dialog.
> 2. The UI for plugins still has some issues, e.g. the online banking
> plugins which are loaded on demand (and are not deactivatable) have a
> checkbox for loading and unloading which has no function.
> 3. Unloading plugins may not work correctly (I think it never did).
> 4. The payeeIdentifiers are not listet in the plugin settings page.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 09970dd5626e308c443ea20ee20ecf8503b21209 
>   kmymoney/CMakeLists.txt acbe6a3c91a62a15871a0061486a7d0771b3a5e6 
>   kmymoney/dialogs/konlinetransferform.h 
> e4761904d68a92471c0b05cc9e5b2bcd1461511d 
>   kmymoney/dialogs/konlinetransferform.cpp 
> 07e73ab17f93cd8fd804b9d11ede2b049f76eefe 
>   kmymoney/dialogs/settings/ksettingsplugins.cpp 
> 007a59d4be08fe779245dd5d52f664ebfcee447d 
>   kmymoney/kmymoney.h 8d10023b5e35be8f4449973ea16e0ec0cc0acca2 
>   kmymoney/kmymoney.cpp 043342dd87cbc03557c5e2b29eb3b9dfcd1083dd 
>   kmymoney/mymoney/onlinejobadministration.h 
> e72d1a6e46c7c8bcc7cf05193e04bdc8bd9103f5 
>   kmymoney/mymoney/onlinejobadministration.cpp 
> 52658747a44bc5477ccd75a531aef471b4553b19 
>   kmymoney/pluginloader.h PRE-CREATION 
>   kmymoney/pluginloader.cpp PRE-CREATION 
>   kmymoney/plugins/CMakeLists.txt fd7cad75256c0a43d7d1fd3a23b37cef7fab8bf9 
>   kmymoney/plugins/csvexport/CMakeLists.txt 
> 9f2e29fd43e32cd3c6acc7f597c45d522eac4eaf 
>   kmymoney/plugins/csvexport/csvexport.json.in PRE-CREATION 
>   kmymoney/plugins/csvexport/csvexporterplugin.h 
> f163ade2d59ae1b6eb32958a317384e77a658523 
>   kmymoney/plugins/csvexport/csvexporterplugin.cpp 
> 31027c65111edbad8ca78b00f5b7df572056bb37 
>   kmymoney/plugins/csvexport/kmm_csvexport.desktop 
> 95

Openning of Databases fails

[Christian David]

Hello,

I cannot open my old databases anymore. The query which causes the problem is 
attached. Note that there are more colums in INSERT INTO than in the SELECT 
(the costCenterId) — which will obviously fail.

We really need a new strategy for the database backend, the current state is 
not tenable.

Greetings
Christian


Driver = QSQLITE, Host = localhost, User = xxx, Database = xxx/kmymoney-
testfiles/tset.sqlite
Driver Error: 
Database Error No -1: 
Text:  
Error type 0
Executed: INSERT INTO kmmSplits (transactionId, txType, splitId, payeeId, 
reconcileDate, action, reconcileFlag, value, valueFormatted, shares, 
sharesFormatted, price, priceFormatted, memo, accountId, costCenterId, 
checkNumber, postDate, bankId) SELECT transactionId, txType, splitId, payeeId, 
reconcileDate, action, reconcileFlag, value, valueFormatted, shares, 
sharesFormatted, price, priceFormatted, memo, accountId, checkNumber, postDate, 
bankId FROM kmmtmpSplits;
Query error No -1: No query Unable to fetch row
Error type 1
void MyMoneyStorageSql::cancelCommitUnit(const QString&) - bool 
MyMoneyStorageSql::alterTable(const MyMoneyDbTable&, int) s/be int 
MyMoneyStorageSql::upgradeToV9()
terminate called after throwing an instance of 'MyMoneyException'

[kmymoney4] [Bug 373217] New: The defaults button in KMyMoney's settings does not reset all options

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=373217

Bug ID: 373217
   Summary: The defaults button in KMyMoney's settings does not
reset all options
   Product: kmymoney4
   Version: git (master)
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: kmymoney-devel@kde.org
  Reporter: christian-da...@web.de
  Target Milestone: ---

Not all elements are reset to their default value if the corresponding button
is pressed.

A not complete list of such elements:

Scheduled transactions -> Use holiday calendar for region
Ledger -> Data entry -> Autofill

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Review Request 129393: Use Qt's plugin system instead of KService

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129393/
---

(Updated Nov. 26, 2016, 3:12 p.m.)


Status
--

This change has been marked as submitted.


Review request for KMymoney.


Changes
---

Submitted with commit 82fbbb1ab2e245df5958f805ed72abcbe3b1b8e6 by Christian 
Dávid to branch master.


Repository: kmymoney


Description
---

Hi,

this is my long overdue change on the plugin system. It actually started in 
Randa.

Sorry for such a long review request! I think it is ready for publishing, I 
made this review request only to give everybody a chance to ask questions :)


Commit 1


This is a major change. Instead of a KPluginFactory based plugin
loading, Qt's plugin system is used. The docu was adopeted to reflect
this.

Commit 2


The plugins for onlineTasks are now loaded with QPluginLoader on demand.
The necessary information is encoded in Qt's json plugin header.

Commit 3


Moved plugin loader out of kmm_plugin and put it into the executable

The plugin shared library is for plugins now and does not include the
loading of plugins (which was kind of wired). All loading operations of
standard plugins is done in KMyMoneyApp now.

Therefor the interface system for plugins needed do be reworked to
great degree. Some overly complex operations were replaced by simpler
ones. All plugins were adopted to that. Also it is more type safe now.

Now the user configuration which plugins should be loaded or not is
respected (standard plugins only).

An old bug was fixed: If the configuration in the plugin settings
changed the plugins are loaded/unloaded after the user accepts the
dialog (perviously this was done when the checkbox was clicked).

Todos
=

The new system is still not finished. However, it is a great step in
the right direction. An uncomplete list of FIXMEs (or bugs?):

1. pluginloader.{h,cpp} are gui only now and should be merged into the
settings dialog.
2. The UI for plugins still has some issues, e.g. the online banking
plugins which are loaded on demand (and are not deactivatable) have a
checkbox for loading and unloading which has no function.
3. Unloading plugins may not work correctly (I think it never did).
4. The payeeIdentifiers are not listet in the plugin settings page.


Diffs
-

  CMakeLists.txt 09970dd5626e308c443ea20ee20ecf8503b21209 
  kmymoney/CMakeLists.txt acbe6a3c91a62a15871a0061486a7d0771b3a5e6 
  kmymoney/dialogs/konlinetransferform.h 
e4761904d68a92471c0b05cc9e5b2bcd1461511d 
  kmymoney/dialogs/konlinetransferform.cpp 
07e73ab17f93cd8fd804b9d11ede2b049f76eefe 
  kmymoney/dialogs/settings/ksettingsplugins.cpp 
007a59d4be08fe779245dd5d52f664ebfcee447d 
  kmymoney/kmymoney.h 8d10023b5e35be8f4449973ea16e0ec0cc0acca2 
  kmymoney/kmymoney.cpp 043342dd87cbc03557c5e2b29eb3b9dfcd1083dd 
  kmymoney/mymoney/onlinejobadministration.h 
e72d1a6e46c7c8bcc7cf05193e04bdc8bd9103f5 
  kmymoney/mymoney/onlinejobadministration.cpp 
52658747a44bc5477ccd75a531aef471b4553b19 
  kmymoney/pluginloader.h PRE-CREATION 
  kmymoney/pluginloader.cpp PRE-CREATION 
  kmymoney/plugins/CMakeLists.txt fd7cad75256c0a43d7d1fd3a23b37cef7fab8bf9 
  kmymoney/plugins/csvexport/CMakeLists.txt 
9f2e29fd43e32cd3c6acc7f597c45d522eac4eaf 
  kmymoney/plugins/csvexport/csvexport.json.in PRE-CREATION 
  kmymoney/plugins/csvexport/csvexporterplugin.h 
f163ade2d59ae1b6eb32958a317384e77a658523 
  kmymoney/plugins/csvexport/csvexporterplugin.cpp 
31027c65111edbad8ca78b00f5b7df572056bb37 
  kmymoney/plugins/csvexport/kmm_csvexport.desktop 
957a9edc4101504e0db08378392e29358327b1c6 
  kmymoney/plugins/csvimport/CMakeLists.txt 
c3e13285944f3624d69f7cc7cde0d4d9014a2a2c 
  kmymoney/plugins/csvimport/csvimport.json.in PRE-CREATION 
  kmymoney/plugins/csvimport/csvimporterplugin.h 
e66f9cf8e7bfdf9a431d7c57db2e905f5e89ec66 
  kmymoney/plugins/csvimport/csvimporterplugin.cpp 
9a28dca3efd54b82882ef71595439d34b09a5177 
  kmymoney/plugins/csvimport/kmm_csvimport.desktop 
52dfc6ef5a425f70f4caba42e92378665926c774 
  kmymoney/plugins/icalendarexport/CMakeLists.txt 
b85f29282114b5c8eb4d680308da59177992a7e6 
  kmymoney/plugins/icalendarexport/icalendarexport.h 
ae02cb35041c7bb1423fe2939da1252d1003065a 
  kmymoney/plugins/icalendarexport/icalendarexport.cpp 
d1028338c8e3644fc280395c5c853d369f19f4eb 
  kmymoney/plugins/icalendarexport/kmm_icalendarexport.desktop 
4313fdf277f82e6759e48931b3b2aba059b2ece3 
  kmymoney/plugins/icalendarexport/kmm_icalendarexport.json.in PRE-CREATION 
  kmymoney/plugins/interfaceloader.h PRE-CREATION 
  kmymoney/plugins/interfaceloader.cpp PRE-CREATION 
  kmymoney/plugins/interfaces/kmmviewinterface.h 
d86e5efafd7ceac57b5a107696ffbc57ef64896b 
  kmymoney/plugins/kbanking/CMakeLists.txt 
7a6b656eaa198b0556dc9329c37d9fe34009ad68 
  kmymoney/plugins/kbanking/kbanking.json.in PRE-CREATION 
  kmymoney/plugins

Re: Review Request 129393: Use Qt's plugin system instead of KService

[Christian David]

> On Nov. 17, 2016, 9:09 a.m., Thomas Baumgart wrote:
> > CMakeLists.txt, line 199
> > <https://git.reviewboard.kde.org/r/129393/diff/1/?file=485339#file485339line199>
> >
> > Where did this go? We need it for LIBOFX, don't we?

Hi Thomas,

I moved it into ```kmymoney/plugins/ofximport/CMakeLists.txt``` (I have no clue 
why it is not marked properly). My idea is to keep things which belong together 
in areas as small as possible. Hopefully that encourages people to work on 
small units and taking the fear of working through the hole code base.

Greetings and have a nice weekend!


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129393/#review100896
---


On Nov. 13, 2016, 9:50 p.m., Christian David wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129393/
> ---
> 
> (Updated Nov. 13, 2016, 9:50 p.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Hi,
> 
> this is my long overdue change on the plugin system. It actually started in 
> Randa.
> 
> Sorry for such a long review request! I think it is ready for publishing, I 
> made this review request only to give everybody a chance to ask questions :)
> 
> 
> Commit 1
> 
> 
> This is a major change. Instead of a KPluginFactory based plugin
> loading, Qt's plugin system is used. The docu was adopeted to reflect
> this.
> 
> Commit 2
> 
> 
> The plugins for onlineTasks are now loaded with QPluginLoader on demand.
> The necessary information is encoded in Qt's json plugin header.
> 
> Commit 3
> 
> 
> Moved plugin loader out of kmm_plugin and put it into the executable
> 
> The plugin shared library is for plugins now and does not include the
> loading of plugins (which was kind of wired). All loading operations of
> standard plugins is done in KMyMoneyApp now.
> 
> Therefor the interface system for plugins needed do be reworked to
> great degree. Some overly complex operations were replaced by simpler
> ones. All plugins were adopted to that. Also it is more type safe now.
> 
> Now the user configuration which plugins should be loaded or not is
> respected (standard plugins only).
> 
> An old bug was fixed: If the configuration in the plugin settings
> changed the plugins are loaded/unloaded after the user accepts the
> dialog (perviously this was done when the checkbox was clicked).
> 
> Todos
> =
> 
> The new system is still not finished. However, it is a great step in
> the right direction. An uncomplete list of FIXMEs (or bugs?):
> 
> 1. pluginloader.{h,cpp} are gui only now and should be merged into the
> settings dialog.
> 2. The UI for plugins still has some issues, e.g. the online banking
> plugins which are loaded on demand (and are not deactivatable) have a
> checkbox for loading and unloading which has no function.
> 3. Unloading plugins may not work correctly (I think it never did).
> 4. The payeeIdentifiers are not listet in the plugin settings page.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 09970dd5626e308c443ea20ee20ecf8503b21209 
>   kmymoney/CMakeLists.txt acbe6a3c91a62a15871a0061486a7d0771b3a5e6 
>   kmymoney/dialogs/konlinetransferform.h 
> e4761904d68a92471c0b05cc9e5b2bcd1461511d 
>   kmymoney/dialogs/konlinetransferform.cpp 
> 07e73ab17f93cd8fd804b9d11ede2b049f76eefe 
>   kmymoney/dialogs/settings/ksettingsplugins.cpp 
> 007a59d4be08fe779245dd5d52f664ebfcee447d 
>   kmymoney/kmymoney.h 8d10023b5e35be8f4449973ea16e0ec0cc0acca2 
>   kmymoney/kmymoney.cpp 043342dd87cbc03557c5e2b29eb3b9dfcd1083dd 
>   kmymoney/mymoney/onlinejobadministration.h 
> e72d1a6e46c7c8bcc7cf05193e04bdc8bd9103f5 
>   kmymoney/mymoney/onlinejobadministration.cpp 
> 52658747a44bc5477ccd75a531aef471b4553b19 
>   kmymoney/pluginloader.h PRE-CREATION 
>   kmymoney/pluginloader.cpp PRE-CREATION 
>   kmymoney/plugins/CMakeLists.txt fd7cad75256c0a43d7d1fd3a23b37cef7fab8bf9 
>   kmymoney/plugins/csvexport/CMakeLists.txt 
> 9f2e29fd43e32cd3c6acc7f597c45d522eac4eaf 
>   kmymoney/plugins/csvexport/csvexport.json.in PRE-CREATION 
>   kmymoney/plugins/csvexport/csvexporterplugin.h 
> f163ade2d59ae1b6eb32958a317384e77a658523 
>   kmymoney/plugins/csvexport/csvexporterplugin.cpp 
> 31027c65111edbad8ca78b00f5b7df572056bb37 
>   kmymoney/plugins/csvexport/kmm_csvexport.desktop 
>

[kmymoney4] [Bug 372453] KMyMoney 4.8 crashes on opening some files

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=372453

--- Comment #5 from Christian David <christian-da...@web.de> ---
(In reply to Ralf Habacker from comment #3)
> According to https://scan.coverity.com/projects/kmymoney?tab=overview has
> kmymoney 4.8 about 80 issues related to null pointer deferences. It may help
> to fix them.

That is probably right. I made a commit for KMyMoney 5 to fix this. It should
be easy to back port the patch (unfortunately I cannot make/test it at the
moment). Then we need to evaluate if the bug was actually fixed or if this is
an upstream bug.

However, this shows again that the plugins should have their own thread. A
crash of a plugin (even if we give it invalid data) should not take down
KMyMoney.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 372453] KMyMoney 4.8 crashes on opening some files

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=372453

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 CC|    |christian-da...@web.de
   Priority|NOR |HI
   Severity|crash   |major

--- Comment #1 from Christian David <christian-da...@web.de> ---
Mhh, this looks like a bug for (or caused by) me :(

Can you open KMyMoney within a terminal and send me the console output?

Do you use aqBanking (HBCI/FinTS)? If not, you can disable the aqbanking plugin
in the settings. This work around could solve the crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 372263] KMyMoney crashes on opening

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=372263

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC|    |christian-da...@web.de

--- Comment #2 from Christian David <christian-da...@web.de> ---
Thank you for this update!

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Review Request 129393: Use Qt's plugin system instead of KService

[Christian David]

> On Nov. 14, 2016, 7:17 a.m., Marko Käning wrote:
> > Why do you migrate away from KService to something Qt'ish?

Because there is no use of KService for us. Also this is way simpler. The new 
system is recommended by the Frameworks developers (if KService is not needed).

The on demand plugins still use KService to find plugins.

Btw: This patch includes the KF5/Qt5 port of the plugin load system.


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129393/#review100826
---


On Nov. 13, 2016, 9:50 p.m., Christian David wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129393/
> ---
> 
> (Updated Nov. 13, 2016, 9:50 p.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Hi,
> 
> this is my long overdue change on the plugin system. It actually started in 
> Randa.
> 
> Sorry for such a long review request! I think it is ready for publishing, I 
> made this review request only to give everybody a chance to ask questions :)
> 
> 
> Commit 1
> 
> 
> This is a major change. Instead of a KPluginFactory based plugin
> loading, Qt's plugin system is used. The docu was adopeted to reflect
> this.
> 
> Commit 2
> 
> 
> The plugins for onlineTasks are now loaded with QPluginLoader on demand.
> The necessary information is encoded in Qt's json plugin header.
> 
> Commit 3
> 
> 
> Moved plugin loader out of kmm_plugin and put it into the executable
> 
> The plugin shared library is for plugins now and does not include the
> loading of plugins (which was kind of wired). All loading operations of
> standard plugins is done in KMyMoneyApp now.
> 
> Therefor the interface system for plugins needed do be reworked to
> great degree. Some overly complex operations were replaced by simpler
> ones. All plugins were adopted to that. Also it is more type safe now.
> 
> Now the user configuration which plugins should be loaded or not is
> respected (standard plugins only).
> 
> An old bug was fixed: If the configuration in the plugin settings
> changed the plugins are loaded/unloaded after the user accepts the
> dialog (perviously this was done when the checkbox was clicked).
> 
> Todos
> =
> 
> The new system is still not finished. However, it is a great step in
> the right direction. An uncomplete list of FIXMEs (or bugs?):
> 
> 1. pluginloader.{h,cpp} are gui only now and should be merged into the
> settings dialog.
> 2. The UI for plugins still has some issues, e.g. the online banking
> plugins which are loaded on demand (and are not deactivatable) have a
> checkbox for loading and unloading which has no function.
> 3. Unloading plugins may not work correctly (I think it never did).
> 4. The payeeIdentifiers are not listet in the plugin settings page.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 09970dd5626e308c443ea20ee20ecf8503b21209 
>   kmymoney/CMakeLists.txt acbe6a3c91a62a15871a0061486a7d0771b3a5e6 
>   kmymoney/dialogs/konlinetransferform.h 
> e4761904d68a92471c0b05cc9e5b2bcd1461511d 
>   kmymoney/dialogs/konlinetransferform.cpp 
> 07e73ab17f93cd8fd804b9d11ede2b049f76eefe 
>   kmymoney/dialogs/settings/ksettingsplugins.cpp 
> 007a59d4be08fe779245dd5d52f664ebfcee447d 
>   kmymoney/kmymoney.h 8d10023b5e35be8f4449973ea16e0ec0cc0acca2 
>   kmymoney/kmymoney.cpp 043342dd87cbc03557c5e2b29eb3b9dfcd1083dd 
>   kmymoney/mymoney/onlinejobadministration.h 
> e72d1a6e46c7c8bcc7cf05193e04bdc8bd9103f5 
>   kmymoney/mymoney/onlinejobadministration.cpp 
> 52658747a44bc5477ccd75a531aef471b4553b19 
>   kmymoney/pluginloader.h PRE-CREATION 
>   kmymoney/pluginloader.cpp PRE-CREATION 
>   kmymoney/plugins/CMakeLists.txt fd7cad75256c0a43d7d1fd3a23b37cef7fab8bf9 
>   kmymoney/plugins/csvexport/CMakeLists.txt 
> 9f2e29fd43e32cd3c6acc7f597c45d522eac4eaf 
>   kmymoney/plugins/csvexport/csvexport.json.in PRE-CREATION 
>   kmymoney/plugins/csvexport/csvexporterplugin.h 
> f163ade2d59ae1b6eb32958a317384e77a658523 
>   kmymoney/plugins/csvexport/csvexporterplugin.cpp 
> 31027c65111edbad8ca78b00f5b7df572056bb37 
>   kmymoney/plugins/csvexport/kmm_csvexport.desktop 
> 957a9edc4101504e0db08378392e29358327b1c6 
>   kmymoney/plugins/csvimport/CMakeLists.txt 
> c3e13285944f3624d69f7cc7cde0d4d9014a2a2c 
>   kmymoney/plugins/csvimport/csvimport.json.in PRE-CREATION 
>   kmymon

Review Request 129393: Use Qt's plugin system instead of KService

[Christian David]

 
ad53d4ba608e221a920a4899ebbfab7466c0293f 
  kmymoney/plugins/kmymoney-onlinetaskui.desktop 
23cfd182a0e12c0be9a97f0490ceedc3456f1b84 
  kmymoney/plugins/kmymoney-payeeidentifierdelegate.desktop 
cc2689f5c1f36ac4d75d1d6bd7ce0c0877b7ca18 
  kmymoney/plugins/kmymoney-plugin.desktop 
28673a8ed8ff8578f046c02b67da4e305f610ecf 
  kmymoney/plugins/kmymoneyplugin.h 12748dc80cca025212d53db13f0e7ccce71cc465 
  kmymoney/plugins/kmymoneyplugin.cpp b55b497607089c4cf036696695b79fd341ec9a3a 
  kmymoney/plugins/ofximport/CMakeLists.txt 
e97b1e87bf1b2141dca623903480691f1f5d0455 
  kmymoney/plugins/ofximport/kmm_ofximport.desktop 
393a0887abbecbf4efb931b8d0ef1da474572025 
  kmymoney/plugins/ofximport/ofximport.json.in PRE-CREATION 
  kmymoney/plugins/ofximport/ofximporterplugin.h 
667a0996654911d58a6d183ba2d0b244a9457172 
  kmymoney/plugins/ofximport/ofximporterplugin.cpp 
46842eee0870c8f2c21678dde112f497b7c8e2a0 
  kmymoney/plugins/onlinejobpluginmockup/CMakeLists.txt 
17db89d743b4f5871aa720654f9fb1af0591bde1 
  kmymoney/plugins/onlinejobpluginmockup/kmm_onlinejobpluginmockup.desktop 
2b5d33c495b342b1cade6d4cbd2b62165c18e29d 
  kmymoney/plugins/onlinejobpluginmockup/kmm_onlinejobpluginmockup.json.in 
PRE-CREATION 
  kmymoney/plugins/onlinejobpluginmockup/onlinejobpluginmockup.h 
f6165d3545d45c1fae6cc72543ffa7750d2a29ee 
  kmymoney/plugins/onlinejobpluginmockup/onlinejobpluginmockup.cpp 
561cf4fa8d925194950e93273810f1d862acf6bf 
  kmymoney/plugins/onlinepluginextended.h 
ec84a2c8867cfbcfb1a54a8d81a484a0c036a656 
  kmymoney/plugins/onlinetasks/sepa/CMakeLists.txt 
30f5e14246a3d63a42e63c886822011fb4496256 
  kmymoney/plugins/onlinetasks/sepa/kmymoney-sepaorders.desktop.in 
c622722047ce8f789f876d4808abd5ee33200bd3 
  kmymoney/plugins/onlinetasks/sepa/kmymoney-sepaorders.json.in PRE-CREATION 
  kmymoney/plugins/onlinetasks/sepa/kmymoney-sepaordersui.desktop.in 
966eb5e7c25938dbb2d12c6427a2f67ec643ff35 
  kmymoney/plugins/onlinetasks/sepa/kmymoney-sepastorageplugin.desktop.in 
a118770c40bfd2040cc9bfd3f68c1538ec44fb09 
  kmymoney/plugins/onlinetasks/sepa/sepaonlinetasksloader.h 
fa6e54f60fffec913bf3f68256aa370b4e5a07b6 
  kmymoney/plugins/onlinetasks/sepa/sepaonlinetasksloader.cpp 
5bf528e9b3cbece1f37af6101f159793bc0c35a6 
  kmymoney/plugins/pluginloader.h 3f7f2ec42d0ef60a6ad2d83601a7dfdc397f4fd6 
  kmymoney/plugins/pluginloader.cpp 20c3b1120c380d3ccec91f412673f18906f5b5f0 
  kmymoney/plugins/printcheck/CMakeLists.txt 
1303f29138a4098824bd5d8209d3a4baadee25da 
  kmymoney/plugins/printcheck/kmm_printcheck.desktop 
97bec6edd7af67582340c14355421e0b121de969 
  kmymoney/plugins/printcheck/kmm_printcheck.json.in PRE-CREATION 
  kmymoney/plugins/printcheck/printcheck.h 
2f16753e35a632593cee5ffb1890b14f6d6a3ff5 
  kmymoney/plugins/printcheck/printcheck.cpp 
8fa469857db50dbb9a3c00f02df38f225ed56017 
  kmymoney/plugins/reconciliationreport/CMakeLists.txt 
19751f5bf13926f60310d1b42be123f5e4ca11ca 
  kmymoney/plugins/reconciliationreport/kmm_reconciliationreport.desktop 
ec3019df28a881dbec5cda3dd1a30df4aa3ec175 
  kmymoney/plugins/reconciliationreport/kmm_reconciliationreport.json.in 
PRE-CREATION 
  kmymoney/plugins/reconciliationreport/reconciliationreport.h 
4d33aa349431deb5b5eb8526d07bfa18a1d77e6d 
  kmymoney/plugins/reconciliationreport/reconciliationreport.cpp 
304b032d5b5ea60114447fb72ff7ac1f317b9e99 
  kmymoney/plugins/weboob/CMakeLists.txt 
b99cc0729847d8217fdec483568b42e6069b9974 
  kmymoney/plugins/weboob/dialogs/mapaccount.h 
041620d2585a5e0e289ba53d89ac7a2ab19768c6 
  kmymoney/plugins/weboob/dialogs/mapaccount.cpp 
f5e36e5a515b58d5a53cb51559569d6fba267bdd 
  kmymoney/plugins/weboob/kmm_weboob.desktop 
1b0ab9e22d7bc3397744eae3ed44fbb30943963b 
  kmymoney/plugins/weboob/kmm_weboob.json.in PRE-CREATION 
  kmymoney/plugins/weboob/plugin.h c7a8ab13c92988b5ea59e4a06035c399e1e2a76d 
  kmymoney/plugins/weboob/plugin.cpp 49dee5e1b3c6190f05ec478e2dac8bb9c3dac5ce 

Diff: https://git.reviewboard.kde.org/r/129393/diff/


Testing
---

Opened KMyMoney with aqbanking enabled and disabled. Checked if the Aqbanking 
Settings menu entry exists.


Thanks,

Christian David

Re: More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5

[Christian David]

Hi Ralf,

I still do not like this. The reason is that this just fixes the symptom, not 
the problem. With these changes we make a huge technical dept. Exept for 
version 4.8 we solved nearly all problems mentioned here already. So all 
changes are only a workaround to enable coinstallablity with a 5 years old 
release (which got perfectly replaced by alkimia 5).

Also adding the version of Qt – a third party library – to the library sounds 
really strange to me. I am sure this will cause more issues in future.

Regarding packaging; if there is really a fine grained configuration needed,  
there are a lot of cmake variables like

CMAKE_SHARED_LIBRARY_SUFFIX [1]
LIBRARY_OUTPUT_PATH [2]
INCLUDEDIR [3]

and probably even more ECM variables to achive this. With them not a single 
line of alkimia has to be changed. The packager can tune everything just the 
way he wants to. This way, someone who just wants to compile alkimia does not 
need to learn our naming conventions.

I really want to get away from the idea to encode any kind of version in the 
library name.

Greetings
Christian


[1] 
https://cmake.org/cmake/help/v3.1/variable/CMAKE_SHARED_LIBRARY_SUFFIX.html
[2] https://cmake.org/cmake/help/v3.1/variable/LIBRARY_OUTPUT_PATH.html
[3] https://api.kde.org/ecm/kde-module/KDEInstallDirs.html?highlight=includedir

P.S.:
The code
> if(QT4_FOUND)
>find_package(LibAalkimia4)
>if(NOT LIBALKIMIA4_FOUND)
>   find_package(LibAalkimia)
>endif()
> else()
>find_package(LibAalkimia5)
> endif()
> 
> if(QT4_FOUND)
>set(QT_SLOT 4)
> else()
>set(QT_SLOT 5)
> endif()
> 
> find_package(LibAalkimia${QT_SLOT})
> ...
> 
> |add_executable( ...) target_link_libraries(
> Alkimia::alkimia)

is way to long. find_package and the config scripts have the task to take such 
burdens of the package user. Probably the last line has to be changed from 
Alkimia::alkimia to Alkimia5::alkimia or so, too.


Am Mittwoch, 2. November 2016, 19:35:49 schrieb Ralf Habacker:
> Am 01.11.2016 um 00:05 schrieb Jack:
> > For Gentoo, if two versions are coinstallable, they get assigned to
> > different "slots" and in this case, I think the slot number would
> > easily correspond to the qt version (4 or 5) to align with other qt
> > and kde packages.  Also, as Gentoo is a source based distro, they
> > really cannot install any files with the same name, so the base
> > libalkimia.so should go to libalkimia4.so and libalkimia5.so.  (One of
> > them could stay libalkimia.so, but why not make things consistent if
> > were changing that much anyway?)
> 
> Collecting all requirements we get the following installation path layout:
> 
> Alikima 6.0.90 Qt4: [on a x86_64 system using /usr/local install prefix]
> -- Installing: /usr/local/lib64/libalkimia4.so.6.0.90
> -- Installing: /usr/local/lib64/libalkimia4.so.6
> -- Installing: /usr/local/lib64/libalkimia4.so
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4Targets.cmake --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4Targets-noconfig.cmake --
> Installing: /usr/local/include/alkimia4-6.0/alkimia/alkvalue.h
> -- Installing: /usr/local/include/alkimia4-6.0/alkimia/alkquoteitem.h
> -- Installing: /usr/local/include/alkimia4-6.0/alkimia/alkcompany.h
> -- Installing: /usr/local/include/alkimia4-6.0/alkimia/alk_export.h
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4Config.cmake [1] --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4ConfigVersion.cmake --
> Installing: /usr/local/lib64/cmake/LibAlkimia4-6.0/FindGMP.cmake --
> Installing: /usr/local/lib64/pkgconfig/libalkimia4.pc [2]
> 
> [1] with LIBALKIMIA4_INCLUDE_DIR=${PACKAGE_PREFIX_DIR}/include/alkimia4-6.0/
> and LIBALKIMIA4_LIBRARIES=${PACKAGE_PREFIX_DIR}/lib64/libalkimia4.so.6.0.90
> [2] with includedir=include/alkimia4-6.0 and Libs:-lalkimia4
> 
> Alkimia 6.0.90 Qt5:  [on a x86_64 system using /usr/local install prefix]
> -- Installing: /usr/local/lib64/libalkimia5.so.6.0.90
> -- Installing: /usr/local/lib64/libalkimia5.so.6
> -- Installing: /usr/local/lib64/libalkimia5.so
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5Targets.cmake --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5Targets-noconfig.cmake --
> Installing: /usr/local/include/alkimia5-6.0/alkimia/alkvalue.h
> -- Installing: /usr/local/include/alkimia5-6.0/alkimia/alkquoteitem.h
> -- Installing: /usr/local/include/alkimia5-6.0/alkimia/alkcompany.h
> -- Installing: /usr/local/include/alkimia5-6.0/alkimia/alk_export.h
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5Config.cmake [1] --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5ConfigVersion.cmake --
> Installi

Re: More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5

[Christian David]

Hi Ralf,

Thanks for this perfect overview! I notice that Alkimia 5 should install its 
cmake files into .../cmake/LibAlkimia-5.0/..., everything else looks okay. The 
cmake files should be in seperate directories because cmake expects it that 
way.

However, we could rename the include directory into alkimia-6.0 (and -5.0). 
Then installing multiple versions is not an issue anymore. It is set by cmake 
anyway. Maybe it should be prefix/include/alkimia-6.0/alkimia/alkvalue.h. Then 
the includes could be #include  and if needed someone 
could create a symlink prefix/include/alkimia -> prefix/include/alkimia-6.0. I 
will check how the frameworks are doing this. 

The /usr/local/lib64/libalkimia.so link should not be an issue. The 
distributions usually do not install it (except in -devel packages). Also the 
find_package() call ensures that the right libalkimia.so.* is selected  (if a 
version is set). All other *.so* shared objects have unique names.

About pkgconfig: Since pkgconfig has no support for multiple versions we could 
rename these files to /usr/local/lib64/pkgconfig/libalkimia-6.0.pc (and change 
the line "Libs: -lalkimia" to contain the so-version). Or is there another 
style for pkgconfig?  Also I doubt that anybody is using it — it was used by 
the former FindAlkimia.cmake script, though. So we are probably save to drop 
it, all projects which use alkimia (KMyMoney, Kraft and Scrooge?!) should be 
cmake based.

Greetings
Christian

Am Montag, 31. Oktober 2016, 12:52:49 schrieb Ralf Habacker:
[…]
> > I would test it myself but have not enought time at the moment (and I do
> > not have any KDE 4 installed anymore, so that would take some time).
> 
> Thanks for your offer. I currently have both KDE4  available, so I can
> check it by myself
> 
> alkimia 6.0 installs
> -- Installing: /usr/local/lib64/libalkimia.so.6.0.90
> -- Installing: /usr/local/lib64/libalkimia.so.6
> -- Installing: /usr/local/lib64/libalkimia.so
> -- Installing: /usr/local/lib64/cmake/LibAlkimia-6.0/LibAlkimiaTargets.cmake
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia-6.0/LibAlkimiaTargets-noconfig.cmake
> -- Installing: /usr/local/include/alkimia/alkvalue.h
> -- Installing: /usr/local/include/alkimia/alkquoteitem.h
> -- Installing: /usr/local/include/alkimia/alkcompany.h
> -- Installing: /usr/local/include/alkimia/alk_export.h
> -- Installing: /usr/local/lib64/cmake/LibAlkimia-6.0/LibAlkimiaConfig.cmake
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia-6.0/LibAlkimiaConfigVersion.cmake
> -- Installing: /usr/local/lib64/cmake/LibAlkimia-6.0/FindGMP.cmake
> -- Installing: /usr/local/lib64/pkgconfig/libalkimia.pc
> 
> and alkimia 5.0
> -- Installing: /usr/local/lib64/libalkimia.so.5.0.0
> -- Installing: /usr/local/lib64/libalkimia.so.5
> -- Installing: /usr/local/lib64/libalkimia.so
> -- Installing: /usr/local/lib64/cmake/LibAlkimia/LibAlkimiaTargets.cmake
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia/LibAlkimiaTargets-relwithdebinfo.cmake
> -- Installing: /usr/local/include/alkimia/alkvalue.h
> -- Installing: /usr/local/include/alkimia/alkquoteitem.h
> -- Installing: /usr/local/include/alkimia/alkcompany.h
> -- Installing: /usr/local/include/alkimia/alk_export.h
> -- Installing: /usr/local/lib64/cmake/LibAlkimia/LibAlkimiaConfig.cmake
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia/LibAlkimiaConfigVersion.cmake
> -- Installing: /usr/local/lib64/pkgconfig/libalkimia.pc
> 
> I tried setting
> 
>  find_package(LibAlkimia 5.0.0 REQUIRED NO_MODULE) and got installed
> version 5.0
>  find_package(LibAlkimia 6.0.0 REQUIRED NO_MODULE) and got installed
> version 6.0
> 
> which works as long as the cmake files are installed in separate
> directories.
> 
> But looking at the file lists above there are still file name conflicts
> for include headers, pkg-config file and /usr/local/lib64/libalkimia.s*o**
> 
> Ralf
> *

Re: More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5

[Christian David]

Am Sonntag, 30. Oktober 2016, 18:49:51 schrieb Ralf Habacker:
[…]
> Your approach also includes the case of a coinstallation, say a stable
> 4.8.x version for real work and kf5 based version for development ?
[…]

Hi Ralf,

If you mean KMyMoney 4.8.x and KF5 then yes. We only need to add the required 
alkimia version to find_package() in KMyMoney.

I would test it myself but have not enought time at the moment (and I do not 
have any KDE 4 installed anymore, so that would take some time).

Greetings
Christian

[kmymoney4] [Bug 370227] Crash on exit

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=370227

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|NEEDSINFO   |UNCONFIRMED

--- Comment #7 from Christian David <christian-da...@web.de> ---
Then my assumption is wrong – seems to be too simple to be true :(

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Review Request 129116: Fix 'Exported templates does not have any title and description'.

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129116/#review100402
---




kmymoney/kmymoney.cpp (line 2185)
<https://git.reviewboard.kde.org/r/129116/#comment67382>

What happens if the user selects the abort button?


- Christian David


On Oct. 17, 2016, 9:07 a.m., Ralf Habacker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129116/
> ---
> 
> (Updated Oct. 17, 2016, 9:07 a.m.)
> 
> 
> Review request for KMymoney and Thomas Baumgart.
> 
> 
> Bugs: 370224
> http://bugs.kde.org/show_bug.cgi?id=370224
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Before exporting a dialog is now shown with which users can fill
> in title, short and long description.
> 
> BUG:370224
> 
> 
> Diffs
> -
> 
>   kmymoney/converter/mymoneytemplate.h 
> 888178bc73b83686e237c6f36761a2eb790c363b 
>   kmymoney/converter/mymoneytemplate.cpp 
> f482779b2e0825e146181e7df9387e741e1437f1 
>   kmymoney/dialogs/CMakeLists.txt 0daa6f63de08a37a7e135ba9b649c35c44fdcbc9 
>   kmymoney/dialogs/ktemplateexportdlg.h PRE-CREATION 
>   kmymoney/dialogs/ktemplateexportdlg.cpp PRE-CREATION 
>   kmymoney/dialogs/ktemplateexportdlg.ui PRE-CREATION 
>   kmymoney/kmymoney.cpp a4251f031cee280983aa67c55447d3f97865dcbd 
> 
> Diff: https://git.reviewboard.kde.org/r/129116/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.8 branch
> 
> 
> Thanks,
> 
> Ralf Habacker
> 
>

[kmymoney4] [Bug 371806] KMyMoney crashes when updating transactions of newly created credit card account

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=371806

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 CC|    |christian-da...@web.de
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Christian David <christian-da...@web.de> ---
Can you update the credit card in GnuCash?

*** This bug has been marked as a duplicate of bug 371055 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 370227] Crash on exit

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=370227

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 CC|    |christian-da...@web.de
 Resolution|--- |INVALID
 Status|UNCONFIRMED |NEEDSINFO

--- Comment #1 from Christian David <christian-da...@web.de> ---
Here KMyMoney is used with Qt 4 and gwenhyfar with Qt 5 – if libkdeui.5.dylib
is KF 5 based. This is probably the reason for the crash.

Can you check if my assumption is correct?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 371055] crash while attempting to update account / download bank transactions

[Christian David]

https://bugs.kde.org/show_bug.cgi?id=371055

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 CC|    |christian-da...@web.de

--- Comment #1 from Christian David <christian-da...@web.de> ---
Are you using HBCI/FinTS or QIF?

I think aqbanking does not support requesting credit card statements using
HBCI/FinTS. So a legal work around is to unmap the credit card account from
aqbanking (so no updates are done with this account anymore).

However, KMyMoney should not crash at all. From a first glance the crash seems
to be in KMyMoney's core (called by the aqbanking plugin).

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: libalkimia 4.3.2 support in kmm 4.8

[Christian Dávid]

Hi timothy,

the information that alkimia <= 6.0.0 fetches Qt 5 is wrong!

Alkimia <= 5 is Qt 4 based, it is fetched indirectly over the line

find_package(KDE4 4.6.0 REQUIRED)

As written in another thread, the issue is that alkimia 4.x shippes a find 
module which just finds any version of alkimia. Maybe there are other bugs in 
the cmake files, too. However, most of these issues should be fixed in version 
5.

Greetings
Christian

> timothy <timbo...@afrihost.co.za> hat am 18. Oktober 2016 um 09:42 
> geschrieben:
> 
> 
> Hi
> I am using LMDE2 Mint Debian and cannot add libalkimia >= 5.0 without
> major changes to my whole system. A recent post from Alan mentions:-
> 
> >> alkimia >= 5.0.0 fetches Qt5 dependencies into a project using it.
> >> You need to revert alkimia to  version <= 4.3.2. Another option would be
> >> to (re)add Qt4 support to recent alkimia.
> 
> If consideration is being given to the latter option, would not
> reverting to alkimia 4.3.2 achieve the same purpose. Or at least a
> compile/make option for this version of libalkimia. This would allow
> people with my predicament to get bugs and changes sorted out from
> compiling kmm 4.8 instead of waiting for the next release.
> 
> Regards
> Timothy
> 
> 
> 
> 
>

Re: More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5

[Christian Dávid]

Hello All,

I am sorry that I answer this late. Hopefully I can still help.

The cause of all trouble in alkimia is that the version checking is not done 
correctly. Pre alkimia 5 had a find module (which is wrong in the first place) 
which did not check any version. Also it would find any alkimia version 
(including 5 & 6).

So renaming the cmake find module and config file will not fix that issue! Even 
the hack of Thomas in KMyMoney's config file to prevent pulling version 6 does 
not work here because the find module does not even provide any version 
information.

In Version 5 I made a mistake, so alkimia 5 marks itself "COMPATIBILITY 
AnyNewerVersion" (this includes v6.0 v7.0...). However this is not an issue 
here. If it is easy to publish a version 5.0.1 we should fix that.

My current suggestion to solve this issue is:

1) Let alkimia 4 die. Alkimia 5 is a perfect replacement. The only reason for 
the version jump was a really tiny change which caused ABI incompatibility. Any 
code that compiles with alkimia 4 should compile with version 5, too. Also no 
change in any CMakeLists.txt is needed if no alkimia >= 6 is on the system.

2) In KMyMoney we add the CONFIG option to find_package(). Then alkimia <= 4 is 
not found anymore. Also we add correct version information to the 
find_package() call. The hand written check should be removed. CMake has a 
powerful version checking system, we should relay on that!

Then no complicated naming conventions have to be introduced (which will not 
solve all issues, btw).

Greetings
Christian

> Thomas Baumgart <t...@net-bembel.de> hat am 23. Oktober 2016 um 10:46 
> geschrieben:
> 
> 
> Hi,
> 
> On Saturday 22 October 2016 23:20:14 Ralf Habacker wrote:
> 
> > Am 22.10.2016 um 20:02 schrieb Jack:
> 
> [...]
>  
> > > Am I just trying the impossible?
> > 
> > No, I just pushed a commit to a personal repo at
> > https://github.com/rhabacker/alkimia, which readd's Qt4 support to
> > latest version of alkimia. You can build and install alkimia side by
> > side to the Qt5 variant. You may try that. See the commit log how to
> > build alkimia in this way.
> 
> I took a glimpse and this seems to make sense. Would then in KMyMoney 4.8 
> something like
> 
>   find_package(LibAlkimiaQt4)
>   if (not found)
> find_package(LibAlkimia REQUIRED)
>   endif()
> 
> be possible to further automate for both scenarios? In case it is found, we 
> need to make sure the version check only applies to the Qt5 version if found 
> by that second find_packages() statement above, or am I missing something?
> 
> I believe my cmake foo comes to an end here really soon :)
> 
> 
> 
> -- 
> 
> Regards
> 
> Thomas Baumgart
> 
> GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
> -
> Memory's the second thing to go ... Can't remember the first.
> -

Re: problems compiling 4.8 on system with both qt4 and qt5

[Christian Dávid]

Hi Ralf,

are you sure? Alkimia 5 is Qt4 & KDE4 based! The first alkimia version with Qt 
5 is/will be alkimia 6. There should be no reason to use 4.x anymore.

Greetings
Christian

> Ralf Habacker <ralf.habac...@freenet.de> hat am 17. Oktober 2016 um 08:44 
> geschrieben:
> 
> 
> Am 17.10.2016 um 00:52 schrieb Jack:
> > Something Alan sent me made me look and think it might have been
> > because alkimia was compiled with qt5, but I'm no longer sure about that.
> alkimia >= 5.0.0 fetches Qt5 dependencies into a project using it. You
> need to revert alkimia to  version <= 4.3.2. Another option would be to
> (re)add Qt4 support to recent alkimia.
> 
> Ralf
>

Re: KPluginInfo::fromServices

[Christian Dávid]

Hi Łukasz,

I already replaced it (it is way simpler now, no .desktop files needed 
anymore). Unfortunately some of my changes broke something so I will need some 
more time to fix that.

Please do not change anything regarding the plugin system at the moment – I 
changed a lot! Unfortunately I have no time to continue my work in October. 
However, I hope to (and look forward to) hack on KMyMoney in near future again.

Greetings
Christian

> Łukasz Wojniłowicz <lukasz.wojnilow...@gmail.com> hat am 2. Oktober 2016 um 
> 13:10 geschrieben:
> 
> 
> Hi all!
> 
> Is anybody already working on replacing deprecated KPluginInfo::fromServices 
> in pluginloader.cpp?
> If not I would like to try it. Any pointers are welcome :)
> 
> Cheers
> Łukasz

Re: [kmymoney/4.8] /: Another cmake fix.

[Christian Dávid]

Hi Ralf,

I think it should be

if (${LibAlkimia_FOUND} AND DEFINED LibAlkimia_VERSION)

without ${}. This explains why you had an error if LibAlkimia_VERSION is not 
defined — because the expresion evaluates to "if (${LibAlkimia_FOUND} AND 
DEFINED)".

Also I want to highlight that Alkimia 6 uses the version parameter of 
find_package(). If there is something lower than version 6 required, it aborts. 
The find modules should not care about that additional parameter (unfortunatly 
I cannot test this because I cannot compile the 4.8 branch at the moment). So 
the whole test logic is not needed anymore.

Greetings
Christian

P.S.: @Thomas, I know this branch is at its end of lifetime. However, this 
seems to be more work than thought.

> Ralf Habacker <ralf.habac...@freenet.de> hat am 30. September 2016 um 09:48 
> geschrieben:
> 
> 
> Git commit 966efeb610171695686f936cc2bcd4956f5cd2e3 by Ralf Habacker.
> Committed on 30/09/2016 at 07:47.
> Pushed by habacker into branch '4.8'.
> 
> Another cmake fix.
> 
> CMake 3.5 also does not like to have DEFINED together with another
> statement in an if statement.
> 
> M  +5-3CMakeLists.txt
> 
> http://commits.kde.org/kmymoney/966efeb610171695686f936cc2bcd4956f5cd2e3
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 2257bd9..08d1803 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -118,9 +118,11 @@ if (NOT LIBALKIMIA_LIBRARIES AND LIBALKIMIA_LIBRARY)
>set(LIBALKIMIA_LIBRARIES ${GMP_LIBRARIES} ${LIBALKIMIA_LIBRARY} )
>  endif()
>  # make sure we have the matching version of LibAlkimia (not too new)
> -if(${LibAlkimia_FOUND} AND DEFINED ${LibAlkimia_VERSION})
> -if (NOT "${LibAlkimia_VERSION}" VERSION_LESS "6.0.0")
> -message(FATAL_ERROR "This version of KMyMoney requires LibAlkimia < 
> 6.0.0 and does not work with the installed version of LibAlkimia")
> +if(${LibAlkimia_FOUND})
> +if (DEFINED ${LibAlkimia_VERSION})
> +if (NOT "${LibAlkimia_VERSION}" VERSION_LESS "6.0.0")
> +message(FATAL_ERROR "This version of KMyMoney requires 
> LibAlkimia < 6.0.0 and does not work with the installed version of 
> LibAlkimia")
> +endif()
>  endif()
>  endif()
>  
>

[kmymoney4] [Bug 321649] No input form dialog appears when i try to add a new account in aqbanking

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=321649

--- Comment #6 from Christian David <christian-da...@web.de> ---
I have this issue from time to time. Usually it is caused by some missing
plugins or incorrect paths (there are many in aqbanking). Maybe the package was
defect.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 362373] CSS for home screen and reports cannot be loaded

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362373

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |REOPENED

--- Comment #15 from Christian David <christian-da...@web.de> ---
Requested info received. Set status to reopened.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 362373] CSS for home screen and reports cannot be loaded

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362373

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 CC|    |christian-da...@web.de
Summary|layout seems to be changed  |CSS for home screen and
   |to TXT mode, losing HTML|reports cannot be loaded
   |formats |

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: incompatible moc ?

[Christian Dávid]

Hi all,

I also fixed this on alkimia's side: 
http://commits.kde.org/alkimia/4740a44ba5789cdca44a1a0bbea7faec2a2af64e

Greetings
Christian

> Thomas Baumgart <t...@net-bembel.de> hat am 10. August 2016 um 21:28 
> geschrieben:
> 
> 
> HI
> 
> On Tuesday 09 August 2016 22:33:52 MK wrote:
> 
> > Hi Christian.
> > 
> > > probably you updated Qt between two builds. Use "make clean" to remove the
> > > old moc files. They will be recreated in the next build.
> > Thanks for your thoughts on that.
> > 
> > Problem was that I used libalkimia from the master branch of the git
> > repository (6.0.90). I has got dependencies to Qt5. Only libalkimia 5.0
> > can be used together with kmm 4.8.0.
> > 
> > Thomas provided a patch to avoid building kmm with libalkimia > 5.0. I
> > think he will upload that patch to the repo to include it into the 4.8.1
> > release.
> 
> Already done: 
> http://quickgit.kde.org/?p=kmymoney.git=commit=417881ed4ae5416fa1c0febfbda657dc0bfb317a

Re: incompatible moc ?

[Christian Dávid]

Hi Martin,

probably you updated Qt between two builds. Use "make clean" to remove the old 
moc files. They will be recreated in the next build.

Greetings
Christian

> MK <mailing...@kkk-web.de> hat am 5. August 2016 um 09:02 geschrieben:
> 
> 
> Hi!
> 
> Building 4.8.0 throws the following errors:
> 
> ***
> 
> [  0%] Building CXX object
> libkgpgfile/CMakeFiles/kgpgfile.dir/kgpgfile.cpp.o
> [  0%] Building CXX object
> libkgpgfile/CMakeFiles/kgpgfile.dir/kgpgfile_automoc.cpp.o
> In file included from
> /usr/local/src/git_repo/kmymoney/debug/libkgpgfile/kgpgfile_automoc.cpp:2:0:
> /usr/local/src/git_repo/kmymoney/debug/libkgpgfile/moc_kgpgfile.cpp:15:2:
> error: #error "This file was generated using the moc from 5.5.1. It"
>  #error "This file was generated using the moc from 5.5.1. It"
>   ^
> /usr/local/src/git_repo/kmymoney/debug/libkgpgfile/moc_kgpgfile.cpp:16:2:
> error: #error "cannot be used with the include files from this version
> of Qt."
>  #error "cannot be used with the include files from this version of Qt."
> 
> ***
> 
> I'm stuck. Do I have to add missing Qt packages?
> 
> Martin
> 
> 
>

[kmymoney4] [Bug 365615] SQL syntax error reported opening MySQL database

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365615

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Latest Commit||http://commits.kde.org/kmym
   ||oney/c0f003134059354e2bc2b1
   ||9ffa1b3ca7a98cbb19
   Version Fixed In||5.0
 Status|CONFIRMED   |RESOLVED

--- Comment #4 from Christian David <christian-da...@web.de> ---
Git commit c0f003134059354e2bc2b19ffa1b3ca7a98cbb19 by Christian Dávid.
Committed on 31/07/2016 at 19:31.
Pushed by christiand into branch 'master'.

Renamed SQL column "order" to "userOrder" in some tables

The name "order" is a reserved keyword. It can be used as identifier but
only if it is escaped. Unfortunately the escape sequence is database
dependent.

This patch is untested as another bug prevents me from opening a
database. Scince this fix is kind of urgent, I publish it anyway. The
port to 4.8 should be straight forward.
FIXED-IN: 5.0

M  +3-3kmymoney/mymoney/storage/mymoneydbdef.cpp
M  +3-3kmymoney/mymoney/storage/mymoneystoragesql.cpp

http://commits.kde.org/kmymoney/c0f003134059354e2bc2b19ffa1b3ca7a98cbb19

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 365615] SQL syntax error reported opening MySQL database

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365615

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #3 from Christian David <christian-da...@web.de> ---
This bug is caused by mymoneydbdef.cpp, line 221. There I used “order” as
column name. This is okay if the identifier is quoted. Unfortunately the way of
quoting it is different between the databases (e.g.
https://www.postgresql.org/docs/7.3/static/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS
vs https://dev.mysql.com/doc/refman/5.7/en/identifiers.html). I did not know
that :(

It should be safe to rename the identifier as we do not really use it, yet.
Alternatively we could adopt our query creator to this. However, I think this
is too much work for a minor benefit.

There is another case of this issue in line 162. If someone is working an this
bug, please assign it to yourself.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 364387] kmymoney 4.8.0 builds libpayeeidentifier.so but asks for libkmm_payeeidentifier.so

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364387

--- Comment #14 from Christian David <christian-da...@web.de> ---
(In reply to David Geiger from comment #12)
> Created attachment 99761 [details]
> kmymoney-4.8.0-fix-libkmm_payeeidentifier-soversion.patch
[…]
> I attached a patch who fixes this library issue.

Hello David,

sorry for not answering that long. The patch you provided should fix the issue.
Unfortunately I cannot not test it at the moment, so I cannot push it. However,
I fixed the bug in the master branch (it is slightly different there). Is there
someone who can compile 4.8 and push the patch from David?

Greetings
Christian

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 364387] kmymoney 4.8.0 builds libpayeeidentifier.so but asks for libkmm_payeeidentifier.so

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364387

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

  Latest Commit||http://commits.kde.org/kmym
   ||oney/4a0fed749df71bb2acfc15
   ||bd6c0bff4806927f01
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Version Fixed In||5.0

--- Comment #13 from Christian David <christian-da...@web.de> ---
Git commit 4a0fed749df71bb2acfc15bd6c0bff4806927f01 by Christian Dávid.
Committed on 12/07/2016 at 20:30.
Pushed by christiand into branch 'master'.

Added versioning to kmm_payeeidentifier library

The missing version caused incorrect naming of the library.
FIXED-IN: 5.0

M  +2-0kmymoney/mymoney/payeeidentifier/CMakeLists.txt

http://commits.kde.org/kmymoney/4a0fed749df71bb2acfc15bd6c0bff4806927f01

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Frameworks branch needs new splash screen

[Christian Dávid]

Hi,

some time ago we contacted the VDG already. So we have some nice ideas for splash screens already:

https://forum.kde.org/viewtopic.php?f=285=119635=105

Greetings
Christian

> Thomas Baumgart <t...@net-bembel.de> hat am 4. Juni 2016 um 07:03 geschrieben:
>
>
> Hi,
>
> On Wednesday 01 June 2016 16:40:01 Jack wrote:
>
> > I don't know if any other artwork needs revising, but certainly the
> > splash screen needs to have the "4" removed, and some reference to
> > "Frameworks" added. I don't know if there are any standard suggestions
> > from the main KDE releases on this topic.
>
> Good point.
>
> > I only found a few old messages related to artwork - does the KDE
> > Artwork Team still exist, and does someone have a connection to ask if
> > they will help with this? Other than that, is there anyone on the list
> > who might work on this?
>
> I just throw in a few links not knowing if they are still actively used:
>
> https://vdesign.kde.org/index.html
> https://forum.kde.org/viewforum.php?f=285
> https://community.kde.org/KDE_Visual_Design_Group
>
> --
>
> Regards
>
> Thomas Baumgart
>
> GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA
> -
> Bachelor: One who is footloose & fiance free!
> -

Re: Plugins path in master branch

[Christian Dávid]

Hi Łukasz,
hi everybody else,

maybe I can clarify some things here. Starting with version 5 KMyMoney will look in the environment variable QT_PLUGIN_PATH for plugins. It is usually set to something like /usr/lib(64)/plugins. Of course the distribution will not require the user to set this variable.

If you run cmake with the variable CMAKE_PREFIX_PATH you change the install dir of the plugins and have to adopt QT_PLUGIN_PATH accordingly (and the other variables Cristian mentioned for other purposes). Note QT_PLUGIN_PATH ≠ CMAKE_PREFIX_PATH. You may need to rerun kbuildsycoca5 after setting this variable.

If you have multiple versions of KMyMoney or plugins installed, you have to set this variable before starting KMyMoney. There are no compile time options for this, the location is always read at runtime from the environment variable (maybe there is a Qt default if the variable is not set). Again you may need to rerun kbuildsycoca5. However, it is totally fine to have multiple versions installed.

There is no additional trouble if you have KF5 and KDE 4 based versions of KMyMoney on your system. Just the variable names differ and of course you have to take care that the install folders of the different versions of KMyMoney do not clash. Some time ago I wrote a longer mail about the KDE 4 variables – that information is still valid. For KMyMoney 5 these variables are not used anymore.

Currently I am rewriting the plugin loader to make it simpler (and to get rid of all the warnings). Then the cache won't be used anymore (for most plugins). You just have to install the plugin into the correct path (it will be QT_PLUGIN_PATH/kmymoney/gui-plugins/). KBuildsycoca5 is not required then. I hope to push this change within the next two weeks. Thanks to the Randa meeting to make this possible!

Greetings
Christian

> Łukasz Wojniłowicz <lukasz.wojnilow...@gmail.com> hat am 18. Juni 2016 um 19:41 geschrieben:
>
>
> Hello community,
>
> I need some wise person to set path to KMM plugins correctly.
>
> Recently, I compiled master branch and was missing CSV importer plugin.
> Following output in terminal:
>
> The environment variable QT_PLUGIN_PATH might be not correctly set
> Error loading plugin "kmm_csvimport" "Shared library not available."
> Plugin search paths are ("/usr/lib64/qt5/plugins", "/usr/bin")
>
> I do:
>
> export QT_PLUGIN_PATH=/usr/lib64/plugins/
>
> and CSV importer plugin is available again. I could fix it in code by myself
> but what is the right approach:
> 1) changing installation path of kmm_csvimport.so,
> 2) changing search path of kmm_csvimport.so,
>
> I hope someone knows better.
>
> Cheers
> Łukasz

[kmymoney4] [Bug 364387] kmymoney 4.8.0 builds libpayeeidentifier.so but asks for libkmm_payeeidentifier.so

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364387

--- Comment #8 from Christian David <christian-da...@web.de> ---
Hi,

in the log you linked I can see that kmm_payeeidentifier is compiled correctly:
"[ 16%] Built target kmm_payeeidentifier"

However, you build failed at a different point. So linking will not work.

CMakeFiles/mymoneyseqaccessmgrtest.dir/mymoneyseqaccessmgrtest.cpp.o: In
function `MyMoneySeqAccessMgrTest::testEmptyConstructor()':
/home/iurt/rpmbuild/BUILD/kmymoney-4.8.0/kmymoney/mymoney/storage/mymoneyseqaccessmgrtest.cpp:61:
undefined reference to `bool QTest::qCompare(unsigned int const&, unsigned long const&, char const*, char const*, char
const*, int)'
/home/iurt/rpmbuild/BUILD/kmymoney-4.8.0/kmymoney/mymoney/storage/mymoneyseqaccessmgrtest.cpp:62:
undefined reference to `bool QTest::qCompare(unsigned int const&, unsigned long const&, char const*, char const*, char
const*, int)'
/home/iurt/rpmbuild/BUILD/kmymoney-4.8.0/kmymoney/mymoney/storage/mymoneyseqaccessmgrtest.cpp:63:
undefined reference to `bool QTest::qCompare(unsigned int const&, unsigned long const&, char const*, char const*, char
const*, int)'
/home/iurt/rpmbuild/BUILD/kmymoney-4.8.0/kmymoney/mymoney/storage/mymoneyseqaccessmgrtest.cpp:64:
undefined reference to `bool QTest::qCompare(unsigned int const&, unsigned long const&, char const*, char const*, char
const*, int)'
/home/iurt/rpmbuild/BUILD/kmymoney-4.8.0/kmymoney/mymoney/storage/mymoneyseqaccessmgrtest.cpp:65:
undefined reference to `bool QTest::qCompare(unsigned int const&, unsigned long const&, char const*, char const*, char
const*, int)'
CMakeFiles/mymoneyseqaccessmgrtest.dir/mymoneyseqaccessmgrtest.cpp.o:/home/iurt/rpmbuild/BUILD/kmymoney-4.8.0/kmymoney/mymoney/storage/mymoneyseqaccessmgrtest.cpp:66:
more undefined references to `bool QTest::qCompare(unsigned int const&, unsigned long const&, char const*, char const*, char
const*, int)' follow
collect2: error: ld returned 1 exit status
kmymoney/mymoney/storage/CMakeFiles/mymoneyseqaccessmgrtest.dir/build.make:194:
recipe for target 'kmymoney/mymoney/storage/mymoneyseqaccessmgrtest' failed
make[2]: *** [kmymoney/mymoney/storage/mymoneyseqaccessmgrtest] Error 1
make[2]: Leaving directory '/home/iurt/rpmbuild/BUILD/kmymoney-4.8.0/build'
CMakeFiles/Makefile2:2838: recipe for target
'kmymoney/mymoney/storage/CMakeFiles/mymoneyseqaccessmgrtest.dir/all' failed
make[1]: ***
[kmymoney/mymoney/storage/CMakeFiles/mymoneyseqaccessmgrtest.dir/all] Error 2

Maybe this and the parallel build cause the linking error you have. I do not
think that your parallel build is the problem, btw.

I think the compiler errors you have were fixed in the 4.8 branch already. Also
you can disable the test, which you may want to do anyway. Setting the cmake
variable "BUILD_TESTING" to off should do this.

libkmm_payeeidentifier.so should be build and installed by KMyMoney. It works
on my system and KDE's CI (there are several tests which depend on
kmm_payeeidentifier).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 364387] kmymoney 4.8.0 builds libpayeeidentifier.so but asks for libkmm_payeeidentifier.so

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364387

--- Comment #2 from Christian David <christian-da...@web.de> ---
Hi José,

unfortunately I cannot reproduce this bug. There must be a Mageia specific
option because we do not create a file called "lib64kmm_mymoney4.so" (only
libkmm_mymoney4.so). There is no library called "libpayeeidentifier.so". I
checked the CMakeLists.txt and they look fine, too.

Can you post your cmake call with all manually set variables?

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: error compiling gwenhywfar for qt5

[Christian Dávid]

Hi Jack,

maybe you can use qmake and qmoc within the /usr/lib/qt/qt5/ directory directly? The configure scripts should be able to handle that (btw: I think qmake is only needed to find the include directory but not used afterwards).

Greetings
Christian

> Jack <ostrof...@users.sourceforge.net> hat am 31. Mai 2016 um 23:12 geschrieben:
>
>
> I'm still waiting to see what the official Gentoo response will be to
> get gwenhywfar to include qt5. I did find some configure hand-waving
> which made it work. Gwenhywfar already has a "--guis='x y z'"
> configure parameter, but just adding qt5 isn't enough. The one thing I
> discovered is that many of the qt related utilities (at least under
> Gentoo) are actually symlinks to a program qtchooser, which calls the
> appropriate version, based either on a command line flag (--qt=5 or
> --qt=4) or else something in the environment. (so "moc --qt=4" or "moc
> --qt=5 as appropriate) Simply adding --qt5-moc='moc --qt=5' to the
> configure was not quite enough but I'd have to go dig up the script I
> used to get the final bit that finally worked.
>
> More details on Gentoo - the actual utilities are under
> /usr/lib/qt/qt4/ and /usr/lib/qt/qt5/ so they can still have the same
> name - it is qtchooser which dispatches the correct one.
>
> Also - the error I got about not finding  was indeed because
> it was still using the qt4 version of qmake (I think.) Once I got the
> qt5 stuff properly included, that problem went away.
[…]

Re: issues with frameworks version

[Christian Dávid]

Hi Jack,

there is a good reason for the three option system (Auto, On and Off). To 
compile a component (e.g. plugin) you can set it to ON. If some prerequisites 
are accidentally missing (e.g. due to an incorrect configuration) cmake will 
abort. This is especially important for automatic tests and automated package 
creation. Just a note: The three way logic was implemented by the KMyMoney 
devs, it is not part of CMake.

You can post any issue here. If you think the issue is caused by your 
configuration and the description costs a lot of time you may want to wait 
after the Randa meeting. Also, I think there should be no reason for a 
“strange” configuration anymore.

Greetings
Christian

> Jack <ostrof...@users.sourceforge.net> hat am 30. Mai 2016 um 02:23 
geschrieben:
> 
> 
> Well, if it's truly AUTO, then is there any reason for a manual  
> setting?  If so, then the setting should be OFF or AUTO, not OFF or  
> ON.  However, I that's really a meta-issue with cmake, not KMM.
> 
> Also, although I've now successfully built the frameworks version, I  
> still have lots of issues - and I'm trying to work my way through them  
> - figuring out if they are reall issues or just due to my strange  
> configuration.  How much effort should I expend before posting such  
> issues here?
>

Re: error compiling gwenhywfar for qt5

[Christian Dávid]

Hi Jack,

I am sorry for answering this late. The solution you found is “the right one”. 
The issue of the configure script is that the name of qmake and moc are 
different if the distribution supports Qt 4 & 5 (moc & moc-qt5 might be good 
guesses). If you (or somebody else) has an idea to make this easier, any 
recommendations are welcome.

Greetings
Christian

> Jack <ostrof...@users.sourceforge.net> hat am 23. Mai 2016 um 23:52 
geschrieben:
> 
> 
> On 2016.05.18 16:26, Jack wrote:
> > Under Gentoo, the ebuild for gwenhywfar-4.15.3 did not have any  
> > reference to qt5, which is clearly needed for KDE Frameworks.   
> > Including qt5 in the guis to be built looks good until compiling  
> > gui/qt5/qt5dialogbox.cpp which includes qt5dialogbox.hpp, which has a  
> > line "#include " which fails with "qt5dialogbox.hpp:16:19:  
> > fatal error: QDialog: No such file or directory".  QDialog is indeed  
> > present under /usr/lib/qt5/QTWidgets/ so I don't see why it shouldn't  
> > find it.
[…]

Re: KF5 release

[Christian Dávid]

Hello,

I assume we can make enough progress in Randa to open the frameworks branch for 
early adopters and power users (with some limitations and missing features). 
Currently I am only developing on the frameworks branch. So I can say that 
KMyMoney is stable enough for developing. However there could still be some 
really bad and hidden issues – I remember the bug where I needed weeks to 
notice that the files were never saved (probably the worst bug we could have).

Greetings
Christian

> Thomas Baumgart <t...@net-bembel.de> hat am 7. Mai 2016 um 09:42 geschrieben:
> 
> 
> Hi,
> 
> first of all: sorry for the late reply. I am just too busy.
> 
> More inline below.
> 
> On Tuesday 26 April 2016 08:37:49 Szőts Ákos wrote:
> 
> > Dear All,
> > 
> > I would like to kindly ask you if you can tell an estimate about the
> > release of KF5 version of KMyMoney. As I see in the commit log [1] the
> > framework branch gets some love from time to time. How usable is it in its
> > current state?
> 
> I cannot really tell, as the frameworks branch is coordinated by Cristian 
> Onet. Maybe he can leave some information about his plans, but I know that he 
> is very busy as well.
> 
> All I can say is, that three KMyMoney devs take part in this years Randa 
> Sprint Meeting for a full week in June and one of the goals is to continue (I 
> try to avoid the word complete here even though it would be nice to reach it) 
> the work on the KF5 version. Another subject in that matter (spread over many 
> teams participating in the meeting) is multiplatform availability.
> 
> http://randa-meetings.ch/2016/02/23/spread-to-more-platforms-registrations-for-randa-meetings-2016-open/
>  has some more details on that.
> 
> > KDEPIM guys did a lot of fixes and features for the PIM in the 16.04
> > version [2]. I love KMyMoney and don't want to abandon it, but I also would
> > like to get the fixes for the rest of the PIM suite.
> 
> We understand that and do our best with the available resources.
> 
> -- 
> 
> Regards
> 
> Thomas Baumgart
> 
> GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
> -
> If you have a choice of two things and can't decide, take both.
>  -- Gregory Corso
> -

RE: Can't build gitHEAD version on windows

[Christian Dávid]

Hi Jeff,

I do not know what "emerge --cleanbuild" does. If it means "remove the hole 
build folder and rebuild" then you found a bug.

Maybe gcc on Linux is more forgiving in this case, so I never saw this. 
However, I will try to fix this. Due to a lot of work this will probably take 
some time. If possible, could you file a bug report? I will mark myself as 
assignee so I cannot forget it.

Greetings
Christian

> jeffjl@outlook.com hat am 7. Mai 2016 um 05:53 geschrieben:
> 
> 
> Hi Christian,
>  
> I just tried 
> "emerge --cleanbuild kmymoney"
>  
> which removed everything under 
> ...\build\extragear\kmymoney-4.6.1-20110918\work\mingw4-RelWithDebInfo-gitHEAD"
>  
>  
> followed by 
> "emerge --update kmymoney".
>  
> Which seems to recompile everything. Still breaks at linking kmymoney.exe due 
> to multiple payeeIdentifierLoader.
>  
> Sorry about the "gitHEAD" nomenclature. That's what the emerge python script 
> uses. It just did a git today from the master branch. In fact, I've been 
> trying this (new git) every month or so since about August 2015. As I recall, 
> it has always had this linking problem. (In the mean time I've just been 
> using the 4.7.2 branch because it builds.)
>  
> I've always assumed it was a Windows thing, and that it would eventually get 
> fixed with the next release (when you tried to build the Windows version).  I 
> just recently chased down what's wrong and decided to ask if it was an easy 
> fix.
>  
> Thanks,
> Jeff.
>  
> > From: christian-da...@web.de
> > To: kmymoney-devel@kde.org
> > Subject: Re: Can't build gitHEAD version on windows
> > Date: Fri, 6 May 2016 20:59:55 +0200
> > 
> > Hi Jeff,
> > 
> > did you use a "make clean" or even better removed the build folder and 
> > rerun 
> > cmake? My gcc on Linux has no problems building it at all.
> > 
> > payeeIdentifierLoader is automatically added to kmymoney.exe because it is 
> > marked "LINK_PUBLIC" in target_link_libraries of kmm_mymoney. This is not 
> > good 
> > (I did it as a work around). If this really needs to be corrected, the 
> > library 
> > has to be build as part of kmm_mymoney with correct export attributes 
> > (which 
> > is some work, so I hope the clean will solve the issue :/)
> > 
> > Greetings
> > Christian
> > 
> > P.S.: I assume you are using the branch master. HEAD and 4.7.90 do not 
> > include 
> > too much info. Especially as "HEAD" is a local ref and can stay the same 
> > forever if you never pull.
> > 
> > Am Freitag, 6. Mai 2016, 15:42:05 CEST schrieb jeffjl@outlook.com:
> > > I got version 4.7.2 to build on windows using emerge and mingw.
> > > 
> > > I have trouble with version 4.7.90. It gets to linking kmymoney.exe and 
> > > gets
> > > "multiple definition of payeeIdentifierLoader".  The problem seems to be
> > > that kmm_mymoney.dll already contains payeeIdentifierLoader but
> > > kmymoney.exe links both the dll and the payeeIdentifierLoader itself.  If 
> > > I
> > > manually edit the
> > > ...work\mingw4-RelWithDebInfo-gitHEAD\kmymoney\CMakeFiles\kmymoney.dir\link
> > > .txt and remove "..\bin\libkmm_payeeidentifier_loader.a", it links OK.  I
> > > cannot figure out how to fix the make files such that
> > > libkmm_payeeidentifier_loader.a is not added to the link.txt file.
> > > 
> > > This same problem occurs linking in some of the test programs (the first 
> > > one
> > > being mymoneyfiletest), but I can work around that by not building the 
> > > test
> > > programs.
> > > 
> > > How does libkmm_payeeidentifier_loader.a get added to the link.txt file?
> > > What do I change to get it to stop doing that?
> > > 
> > > Thanks.
> > > Jeff
> > 
> > 
>

Re: Can't build gitHEAD version on windows

[Christian Dávid]

Hi Jeff,

did you use a "make clean" or even better removed the build folder and rerun 
cmake? My gcc on Linux has no problems building it at all.

payeeIdentifierLoader is automatically added to kmymoney.exe because it is 
marked "LINK_PUBLIC" in target_link_libraries of kmm_mymoney. This is not good 
(I did it as a work around). If this really needs to be corrected, the library 
has to be build as part of kmm_mymoney with correct export attributes (which 
is some work, so I hope the clean will solve the issue :/)

Greetings
Christian

P.S.: I assume you are using the branch master. HEAD and 4.7.90 do not include 
too much info. Especially as "HEAD" is a local ref and can stay the same 
forever if you never pull.

Am Freitag, 6. Mai 2016, 15:42:05 CEST schrieb jeffjl@outlook.com:
> I got version 4.7.2 to build on windows using emerge and mingw.
> 
> I have trouble with version 4.7.90. It gets to linking kmymoney.exe and gets
> "multiple definition of payeeIdentifierLoader".  The problem seems to be
> that kmm_mymoney.dll already contains payeeIdentifierLoader but
> kmymoney.exe links both the dll and the payeeIdentifierLoader itself.  If I
> manually edit the
> ...work\mingw4-RelWithDebInfo-gitHEAD\kmymoney\CMakeFiles\kmymoney.dir\link
> .txt and remove "..\bin\libkmm_payeeidentifier_loader.a", it links OK.  I
> cannot figure out how to fix the make files such that
> libkmm_payeeidentifier_loader.a is not added to the link.txt file.
> 
> This same problem occurs linking in some of the test programs (the first one
> being mymoneyfiletest), but I can work around that by not building the test
> programs.
> 
> How does libkmm_payeeidentifier_loader.a get added to the link.txt file?
> What do I change to get it to stop doing that?
> 
> Thanks.
> Jeff

Re: Review Request 127556: Quit application if all windows were closed, refactor main()

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127556/
---

(Updated May 5, 2016, 6:24 p.m.)


Status
--

This change has been marked as submitted.


Review request for KMymoney and Cristian Oneț.


Changes
---

Submitted with commit ecdbc1c5be7d3a2ced359b80b938b97b3aa86c69 by Christian 
Dávid to branch frameworks.


Repository: kmymoney


Description
---

Allow QApplication to quit if all windows were closed. Otherwise
KMyMoney would never shut down.

Used this commit for minor changes which simplify the code.

Most important is the removal of ```app.setQuitOnLastWindowClosed(false);```. 
Is there a reason why it was added?


Diffs
-

  kmymoney/kmymoney.cpp 0d0a317d753e9c48740180d13235163928687b2c 
  kmymoney/main.cpp cf77030aeb7de0f744bc2cf928514568d564e2e8 

Diff: https://git.reviewboard.kde.org/r/127556/diff/


Testing
---

Started and closed the app.


Thanks,

Christian David

Re: Review Request 127556: Quit application if all windows were closed, refactor main()

[Christian David]

> On April 26, 2016, 10:07 p.m., Christian David wrote:
> > Ship It!
> 
> Cristian Oneț wrote:
> AFAIK app.setQuitOnLastWindowClosed(false); was added because quiting is 
> handled by some custom code which makes sure that the user is prompted to 
> save the file if the file is dirty. If this still works on frameworks with 
> that line removed feel free to ship it. Also please test the import feature 
> using the DBUS call, practically while kmymoney is running if you call 
> kmymoney test.ofx from a shell test.ofx should be imported in the open 
> instance of kmymoney.

The "Do you want to save?" dialog is build into the window, therefore it is not 
affected by this patch (tested it). If I call ```kmymoney test.ofx``` a new 
windows is opened, with and without the patch. So a bug seems to be somewhere 
else.


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127556/#review94877
---


On April 2, 2016, 8:37 p.m., Christian David wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127556/
> ---
> 
> (Updated April 2, 2016, 8:37 p.m.)
> 
> 
> Review request for KMymoney and Cristian Oneț.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Allow QApplication to quit if all windows were closed. Otherwise
> KMyMoney would never shut down.
> 
> Used this commit for minor changes which simplify the code.
> 
> Most important is the removal of ```app.setQuitOnLastWindowClosed(false);```. 
> Is there a reason why it was added?
> 
> 
> Diffs
> -
> 
>   kmymoney/kmymoney.cpp 0d0a317d753e9c48740180d13235163928687b2c 
>   kmymoney/main.cpp cf77030aeb7de0f744bc2cf928514568d564e2e8 
> 
> Diff: https://git.reviewboard.kde.org/r/127556/diff/
> 
> 
> Testing
> ---
> 
> Started and closed the app.
> 
> 
> Thanks,
> 
> Christian David
> 
>

[kmymoney4] [Bug 361876] Poor database performance after update

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361876

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 Status|NEEDSINFO   |RESOLVED
 Resolution|WAITINGFORINFO  |LATER

--- Comment #7 from Christian David <christian-da...@web.de> ---
I checked what we changed between the versions carefully. Unfortunately I could
not find anything that could cause the behavior you have described. The
developers have in mind that the database system has performance issues. If we
have time, we will address that. However, please do not expect a change in near
future. Maybe you should consider to change to a .kmy file.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Review Request 127556: Quit application if all windows were closed, refactor main()

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127556/#review94877
---


Ship it!




Ship It!

- Christian David


On April 2, 2016, 8:37 p.m., Christian David wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127556/
> ---
> 
> (Updated April 2, 2016, 8:37 p.m.)
> 
> 
> Review request for KMymoney and Cristian Oneț.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Allow QApplication to quit if all windows were closed. Otherwise
> KMyMoney would never shut down.
> 
> Used this commit for minor changes which simplify the code.
> 
> Most important is the removal of ```app.setQuitOnLastWindowClosed(false);```. 
> Is there a reason why it was added?
> 
> 
> Diffs
> -
> 
>   kmymoney/kmymoney.cpp 0d0a317d753e9c48740180d13235163928687b2c 
>   kmymoney/main.cpp cf77030aeb7de0f744bc2cf928514568d564e2e8 
> 
> Diff: https://git.reviewboard.kde.org/r/127556/diff/
> 
> 
> Testing
> ---
> 
> Started and closed the app.
> 
> 
> Thanks,
> 
> Christian David
> 
>

Re: Review Request 127679: Change .ui files that use KDialog as the dialog class to QDialog

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127679/#review94876
---



What is the differece to review request #127680?

- Christian David


On April 22, 2016, 5 p.m., Mitch Frazier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127679/
> ---
> 
> (Updated April 22, 2016, 5 p.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> KDialog does not work well with Qt Designer.
> 
> Changing the widget class from KDialog to QDialog is generally
> all that's required.  Even though changing from KDialog to
> QDialog does remove the OK and Cancel buttons in Designer,
> these are added automatically because the dialog class itself
> is still KDialog and it by default adds these buttons.
> 
> One of the dialogs did require the adding of a setButtons() call
> to the constructor to place additional buttons on the dialog
> that were previously specified in the .ui file.
> 
> Before and after screenshots show what the kfindtransactiondlgdecl.ui
> file looks like in Qt Designer before with KDialog and after with QDialog.
> 
> Note that one of the dialogs, ksplittransactiondlgdecl.ui appears to
> be unused and can probably be deleted, although I did not test that.
> 
> 
> Diffs
> -
> 
>   kmymoney/dialogs/kcurrencycalculatordecl.ui 0bcfd40 
>   kmymoney/dialogs/kcurrencyeditdlgdecl.ui 1527455 
>   kmymoney/dialogs/kfindtransactiondlg.cpp 7603007 
>   kmymoney/dialogs/kfindtransactiondlgdecl.ui 44fa861 
>   kmymoney/dialogs/kmymoneypricedlgdecl.ui a484504 
>   kmymoney/dialogs/ksortoptiondlg.ui e7e28e5 
>   kmymoney/dialogs/ksplitcorrectiondlg.ui fb6d337 
>   kmymoney/dialogs/ksplittransactiondlgdecl.ui 6b1c706 
> 
> Diff: https://git.reviewboard.kde.org/r/127679/diff/
> 
> 
> Testing
> ---
> 
> Tested the affected dialogs for correct look and function.
> 
> 
> File Attachments
> 
> 
> Before KDialog
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/17/84cb3eaf-fd0d-44c8-80a3-70fe3d6ba2b3__before-kdialog.png
> After QDialog
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/17/eb4e6c79-c0d0-4d9b-8354-8e82f692cb90__after-qdialog.png
> 
> 
> Thanks,
> 
> Mitch Frazier
> 
>

Re: Review Request 127680: Fix extends tags in .ui files that cause warnings when using the kmymoneywidgets.so plugin.

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127680/#review94874
---


Ship it!




I did not test it. Since ```KDialog``` is deprecated I am okay with this 
change. Also this was done for the frameworks branch already (which is 
important for me).

- Christian David


On April 22, 2016, 5 p.m., Mitch Frazier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127680/
> ---
> 
> (Updated April 22, 2016, 5 p.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Some custom-widgets specified the wrong class that was being
> extended by the widget causing warnings when opening the file
> with Qt Designer.
> 
> These warnings only occur when using the kmymoneywidgets.so plugin
> library for Qt Designer.
> 
> 
> Diffs
> -
> 
>   kmymoney/dialogs/kcurrencycalculatordecl.ui 
> 0bcfd4060338d8659979f8372269fba64f05c6ab 
>   kmymoney/dialogs/kcurrencyeditdlgdecl.ui 
> 1527455a3201ba91c50bee572bc747bba59cd89a 
>   kmymoney/dialogs/kfindtransactiondlg.cpp 
> 76030075141afe04a7aea23a06617be77cf1721d 
>   kmymoney/dialogs/kfindtransactiondlgdecl.ui 
> 44fa86190d035c4652fa9b8129478f6cfcfd6d47 
>   kmymoney/dialogs/kmymoneypricedlgdecl.ui 
> a484504c32f3313d1d6a37551be10f74485ec1d2 
>   kmymoney/dialogs/ksortoptiondlg.ui e7e28e588323b116c5874ad4ac3fee2c28663788 
>   kmymoney/dialogs/ksplitcorrectiondlg.ui 
> fb6d337e746e7d2b5a9b5d355dae46a5dae369bc 
>   kmymoney/dialogs/ksplittransactiondlgdecl.ui 
> 6b1c706a69ab0a289426fbd894068563dcf93e26 
> 
> Diff: https://git.reviewboard.kde.org/r/127680/diff/
> 
> 
> Testing
> ---
> 
> Tested a couple of the dialogs.
> 
> 
> Thanks,
> 
> Mitch Frazier
> 
>

[kmymoney] [Bug 362169] Kmymoney 4.7.2 won't compile and install on Kubuntu 16.04 LTS

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362169

Christian David <christian-da...@web.de> changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEEDSINFO
 Resolution|--- |WAITINGFORINFO
 CC|    |christian-da...@web.de

--- Comment #1 from Christian David <christian-da...@web.de> ---
Can you post the exact error message?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361876] Poor database performance after update

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361876

--- Comment #3 from Christian David <christian-da...@web.de> ---
We can assume that the RDBMS (aka “the database”) is probably not the issue.
The poor performance is caused by the way KMyMoney requests the data from the
RDBMS.

To pinpoint the issue you must use 4.7.2.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Review Request 127678: Register metatypes that are used in Qt Designer files to eliminate warnings.

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127678/#review94753
---



Hi Mitch,

according to the [Qt 
Docu](http://doc.qt.io/qt-5/qmetatype.html#qRegisterMetaType-1) 
```qRegisterMetaType``` is (only) needed under some circumstances:

To use the type T in QVariant, using Q_DECLARE_METATYPE() is sufficient. To 
use the type T in queued signal and slot connections, qRegisterMetaType() 
must be called before the first connection is established.

To prevent complicated issues if we use queued connections ourself in the 
future the ```qRegisterMetaType``` should go somewhere else. I think it should 
be ```mymoneymoney.cpp``` for ```MyMoneyMoney``` but I am unsure here.

- Christian David


On April 18, 2016, 1:03 a.m., Mitch Frazier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127678/
> ---
> 
> (Updated April 18, 2016, 1:03 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Register metatypes to eliminate Qt Desinger warnings.
> 
> Registering metatypes for a type used in a widget eliminates
> the following types of warnings from Qt Designer on start up
> (displayed when designer is started from a console window):
> 
> QMetaProperty::read: Unable to handle unregistered datatype
>   '' for property '::'
> 
> 
> Diffs
> -
> 
>   kmymoney/widgets/kmymoneycurrencyselector.cpp 41be539 
>   kmymoney/widgets/kmymoneyedit.cpp ac79db7 
> 
> Diff: https://git.reviewboard.kde.org/r/127678/diff/
> 
> 
> Testing
> ---
> 
> Tested dialogs that use the data types.
> 
> 
> Thanks,
> 
> Mitch Frazier
> 
>

Re: Suddenly building trouble on OSX for kmymoney's KDE4 master

[Christian David]

Hi Marko,

I checked it. The current tar.gz with version 4.15.2beta does not include the 
current cmake-config files which are required by KMyMoney. I do not know why, 
they were pushed to git some time ago.

Moving to AqBanking’s mailinglist should be the best.

Greetings
Christian

> Marko Käning <mk-li...@mailbox.org> hat am 17. April 2016 um 11:19 
> geschrieben:
> 
> 
> Hi Christian,
> 
> On 17 Apr 2016, at 11:10 , Christian David <christian-da...@web.de> wrote:
> 
> > The missing ...config.cmake files were added recently. Maybe they were not 
> > added to the port (I do not know how macports work)?!
> 
> I am pulling the source tgz’s from upstream directly. So, these files should 
> be in there, no?
> But perhaps they’re generated and OSX has been forgotten up to now…
> 
> OK, will direct my question to AqBanking’s ML.
> 
> Greets,
> Marko

Re: Suddenly building trouble on OSX for kmymoney's KDE4 master

[Christian David]

The missing ...config.cmake files were added recently. Maybe they were not 
added to the port (I do not know how macports work)?!

> Marko Käning  hat am 16. April 2016 um 23:28 
> geschrieben:
> I am not mixing versions of gwenhywfar. Have installed either one or the 
> other. Right now I installed 4.15.2beta even - which has the same problem.
> 
> But well, with 4.14.0 KMM wouldn’t build - as described earlier. I haven’t 
> checked up to now whether the older version still shipped said file.
> 
> I am using downloads directly from upstream, how come this surfaces only for 
> me?

Re: KMM 4.7.2 atrociously slow - unworkable

[Christian David]

Hi Louis-Philippe,

I am surprised this happens. Unfortunately there is no debug mode. However, to 
solve this issue we need to know what exactly causes the slow down. KMyMoney 
does not start any action without prior user interaction (I think). Does it get 
faster again if you just wait long enough (like one or two hours)? What exactly 
did you do before it slows down? Does is slow down if you just open KMyMoney 
and do nothing for some time?

Thank you for testing both versions! This was very important and extremely 
helpful.

Also a last note: I recommend to use a .kmy file. It is way faster and better. 
I am afraid that the database backend is of low quality regarding speed.

Greetings
Christian 

Louis-Philippe Allard <lp.allar...@gmail.com> hat am 10. April 2016 um 00:48 
geschrieben:

since I migrated to 4.7.2 from 4.6.2, KMM became extremely slow, to  
the point of not being able to produce any significant work.  Every  
click of the mouse takes between 5 & 10 seconds no matter what I am  
loading (contextual popup, or loading a ledger, or payees, etc).  This  
is noticeably slower when in the Accounts page but overall, its slow  
to the point that it becomes frustrating to use it.

I eliminated database problems with a replication to another DB, then  
using 4.6.2 on this replicated DB, it is much much faster and snappier  
(when I do something something happens).

I noticed KMM 4.7.2 is fast for a few minutes when I start it back up,  
but after that delay, it becomes hellish.

CPU and RAM are comfortably low (<10% CPU, RAM < 1.5GB) but  
nevertheless, I noticed CPU is always between 7-10% unless I do  
nothing at all (let it alone).

Is there a debug mode or something I could do to pinpoint the source  
of this extreme lack of performance?  Has anybody else noticed 4.7.2  
being notoriously slower than previous releases?

Searching the KDE bugs, bug 360874 seems to be similar or somewhat  
related to what I am experiencing, except that I am running on Linux  
Mint 17.3.  Workstation has quad core AMD Phenom II X4 965 at 3.4GHz,  
and 12GB DDR3-1600 RAM.

Re: Suddenly building trouble on OSX for kmymoney's KDE4 master

[Christian David]

Hi Marko,

actually the missing .pc file is not an issue at all. The 
gwengui-cpp-config.cmake is missing. The version you are using should not cause 
any issue – the only requirement is that you do not mix several versions of 
gwenhyfar. As there is written something about version 4.14 and 4.13 it looks 
like exactly this happened.

Greetings
Christian


> Marko Käning <mk-li...@mailbox.org> hat am 16. April 2016 um 12:57 
> geschrieben:
> 
> 
> Ah, I see, the pc file for cpp is missing:
> 
> ---
> $ port contents gwenhywfar4-devel | grep -- -cpp
>   /opt/local/include/gwenhywfar4/gwen-gui-cpp/api.h
>   /opt/local/include/gwenhywfar4/gwen-gui-cpp/cppdialog.hpp
>   /opt/local/include/gwenhywfar4/gwen-gui-cpp/cppgui.hpp
>   /opt/local/include/gwenhywfar4/gwen-gui-cpp/cppwidget.hpp
>   /opt/local/lib/libgwengui-cpp.0.dylib
>   /opt/local/lib/libgwengui-cpp.a
>   /opt/local/lib/libgwengui-cpp.dylib
> 
> $ port contents gwenhywfar4-devel | grep -- -qt4
>   /opt/local/include/gwenhywfar4/gwen-gui-qt4/qt4_gui.hpp
>   /opt/local/lib/cmake/gwengui-qt4-4.14/gwengui-qt4-config-version.cmake
>   /opt/local/lib/cmake/gwengui-qt4-4.14/gwengui-qt4-config.cmake
>   /opt/local/lib/libgwengui-qt4.0.dylib
>   /opt/local/lib/libgwengui-qt4.a
>   /opt/local/lib/libgwengui-qt4.dylib
>   /opt/local/lib/pkgconfig/gwengui-qt4.pc
> ---
> 
> That’s an upstream issue then.
> 
> Don’t know whether this file exists for version 4.13.0...

Re: Problems building kmymoneywidgets.so

[Christian David]

Hi Mitch,

thank you for your work. Currently the best way to submit patches is to use 
https://git.reviewboard.kde.org to the group KMyMoney.

Greetings
Christian


> Mitch Frazier <mi...@comwestcr.com> hat am 16. April 2016 um 19:22 
> geschrieben:
> 
> 
> Thomas mentioned that he wasn't sure if this library would be needed or not
> in the future, but it seems that currently at least it's useful to have as
> it makes editing some of the .ui files much friendlier.
> 
> Anyways, I have a patch which will fix this.  It's a pretty minor patch,
> just a few #ifndefs and a slight change to a cmakelists file.  What is the
> proper way to submit patches?
> 
> Mitch
> 
> 
> On Wed, Apr 13, 2016 at 3:14 AM, Thomas Baumgart <t...@net-bembel.de> wrote:
> 
> > Hi,
> >
> > On Tuesday 12 April 2016 19:59:48 Mitch Frazier wrote:
> >
> > > I've cloned kmymoney from the git repository and it builds fine, but
> > when I
> > > try to enable the USE_QT_DESIGNER option I get numerous linker errors
> > when
> > > it tries to link kmymoneywidgets.so.  A couple representative errors are
> > > pasted below.  After looking at the code and the errors a bit and seeing
> > > that "kmymoney" is defined in main.cpp, it appears to me that this is an
> > > option that has not been maintained and is currently unusable.  Is that
> > > correct, or should this option be buildable?
> >
> > as Christian pointed out, this is currently broken. It is a leftover from
> > the
> > KDE3 days and I don't know, if we need it again in the future.
> >
> > --
> >
> > Regards
> >
> > Thomas Baumgart
> >
> > GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
> > -
> > Vista is the abrreviation of
> > 'Viruses, Instability, Spyware, Trojans, Adware'...
> > -
> >

Re: Problems building kmymoneywidgets.so

[Christian David]

Hi Mitch,

USE_QT_DESIGNER known to be broken. I recommend to compile KMyMoney without the 
flag. Maybe it works if you enable it later – but probably not.

Greetings
Christian

> Mitch Frazier <mi...@comwestcr.com> hat am 13. April 2016 um 04:59 
> geschrieben:

> I've cloned kmymoney from the git repository and it builds fine, but when I
> try to enable the USE_QT_DESIGNER option I get numerous linker errors when
> it tries to link kmymoneywidgets.so.  A couple representative errors are
> pasted below.  After looking at the code and the errors a bit and seeing
> that "kmymoney" is defined in main.cpp, it appears to me that this is an
> option that has not been maintained and is currently unusable.  Is that
> correct, or should this option be buildable?

Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty

[Christian David]

> On April 7, 2016, 9:59 p.m., Christian David wrote:
> > kmymoney/plugins/csvimport/investprocessing.cpp, line 1967
> > <https://git.reviewboard.kde.org/r/127559/diff/1/?file=455181#file455181line1967>
> >
> > Should become
> > ```m_shrsinList = profilesGroup.readEntry("ShrsinParam", 
> > m_shrsinList);```
> > 
> > The if() is very long and not needed here. However, I still do not know 
> > if this is the issue. Also the ```i18nc()s``` from ```init()``` could go 
> > here if the readSettings method is always called, which I do not know 
> > either.
> 
> Allan Anderson wrote:
> > Should become
> > m_shrsinList = profilesGroup.readEntry("ShrsinParam", m_shrsinList);
> 
> I'm not sure I understand this.  The second parameter is the default 
> value to return if the key is not found.  What does it achieve in this case?
> 
> > The if() is very long and not needed here.
> 
> There are several ifs around here, but I don't see an unduly long one.
> 
> > Also the i18nc()s from init() 
> > could go here if the readSettings method is always called, which I do 
> not know either.
> 
> readSettings is called only once, from void 
> InvestProcessing::slotFileDialogClicked(), so that code could be moved 
> somewhere in void InvestProcessing::readSettings(), I think.
> 
> Łukasz Wojniłowicz wrote:
> > Should become 
> > m_shrsinList = profilesGroup.readEntry("ShrsinParam", m_shrsinList);
> 
> I compiled KMyMoney code according to your change for every m_XXXList 
> variable and ran my test case. Proposed line looks neat but doesn't work for 
> me. SellParam= etc. are empty in my csvimporterrc after just created new 
> profile.
>  
> >readSettings is called only once, from void 
> InvestProcessing::slotFileDialogClicked(), so that code could be moved 
> somewhere in void InvestProcessing::readSettings(), I think.
> 
> Please give a code and I'll test it.
> 
> > I do not know the full conversation but I am pretty sure this patch 
> will not solve the issue. If something in the newly created rc file is 
> missing, the write method seems to fail, not the read method.
> 
> My loose observation: Write method is called at the end of importing and 
> read method is called after creating new importing profile for investment.

> I do not know the full conversation but I am pretty sure this patch will not 
> solve the issue. If something in the newly created rc file is missing, the 
> write method seems to fail, not the read method.

I withdrew this idea. You should not waste your time with it.

> I compiled KMyMoney code according to your change for every m_XXXList 
> variable and ran my test case. Proposed line looks neat but doesn't work for 
> me. SellParam= etc. are empty in my csvimporterrc after just created new 
> profile.

You are right. The code recomended by me has a different behaviour. However, 
now I doubt that anything I wrote was actually helpfull. I just briefly 
inspected the code – now I see that is more complex than I thougt. So my 
recomendations are based on insufficent knowledge. Due to the description in 
the bug report I still think there is a high chance that the issue is in the 
write function.


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127559/#review94397
---


On April 3, 2016, 6:45 a.m., Łukasz Wojniłowicz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127559/
> ---
> 
> (Updated April 3, 2016, 6:45 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 360129
> http://bugs.kde.org/show_bug.cgi?id=360129
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Fixes bug #360129. During creation of new investment statement
> template, transaction types are initialized in
> investprocessing.cpp, but then are overridden with empty fields
> from profile that was just created in csvimporterrc which results
> in every non-buy transaction unrecognized during the import.
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/csvimport/investprocessing.cpp 3879819 
> 
> Diff: https://git.reviewboard.kde.org/r/127559/diff/
> 
> 
> Testing
> ---
> 
> Tested using financial statement from bug #360129.
> 
> 
> Thanks,
> 
> Łukasz Wojniłowicz
> 
>

Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127559/#review94397
---



I withdraw my last comment. I did not see that ```m_buy...``` had an ```if``` 
already. Sorry for more confusion than help :/


kmymoney/plugins/csvimport/investprocessing.cpp (line 1967)
<https://git.reviewboard.kde.org/r/127559/#comment64175>

Should become
```m_shrsinList = profilesGroup.readEntry("ShrsinParam", m_shrsinList);```

The if() is very long and not needed here. However, I still do not know if 
this is the issue. Also the ```i18nc()s``` from ```init()``` could go here if 
the readSettings method is always called, which I do not know either.


- Christian David


On April 3, 2016, 6:45 a.m., Łukasz Wojniłowicz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127559/
> ---
> 
> (Updated April 3, 2016, 6:45 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 360129
> http://bugs.kde.org/show_bug.cgi?id=360129
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Fixes bug #360129. During creation of new investment statement
> template, transaction types are initialized in
> investprocessing.cpp, but then are overridden with empty fields
> from profile that was just created in csvimporterrc which results
> in every non-buy transaction unrecognized during the import.
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/csvimport/investprocessing.cpp 3879819 
> 
> Diff: https://git.reviewboard.kde.org/r/127559/diff/
> 
> 
> Testing
> ---
> 
> Tested using financial statement from bug #360129.
> 
> 
> Thanks,
> 
> Łukasz Wojniłowicz
> 
>

Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty

[Christian David]

> On April 3, 2016, 2:37 p.m., Allan Anderson wrote:
> >
> 
> Allan Anderson wrote:
> We have had discussons about this in the bug report.  I think you are 
> confusing the issue by stating your experience (using the Polish translation) 
> as a general issue.  For me, if I delete the csvimporterrc file and then 
> initiate loading of an investment CSV, a new rc file is created containing 
> default values for all investment types. 
> From the extract of your rc file in the bug report, several investment 
> types have empty fields, although the Buy has an entry.
> 
> Łukasz Wojniłowicz wrote:
> For me, if I delete the csvimporterrc file and then initiate loading of 
> an investment CSV, a new rc file is created containing default value only for 
> Buy and Reinvest Dividend entry.
> I don't understand the confusion you're talking; this patch helps me. Do 
> you say it's wrong?
> 
> Allan Anderson wrote:
> Just to let you know I'm still here.  Have had major system problems, 
> that I'm still recovering from.

I do not know the full conversation but I am pretty sure this patch will not 
solve the issue. If something in the newly created rc file is missing, the 
write method seems to fail, not the read method.


- Christian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127559/#review94211
---


On April 3, 2016, 6:45 a.m., Łukasz Wojniłowicz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127559/
> ---
> 
> (Updated April 3, 2016, 6:45 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 360129
> http://bugs.kde.org/show_bug.cgi?id=360129
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Fixes bug #360129. During creation of new investment statement
> template, transaction types are initialized in
> investprocessing.cpp, but then are overridden with empty fields
> from profile that was just created in csvimporterrc which results
> in every non-buy transaction unrecognized during the import.
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/csvimport/investprocessing.cpp 3879819 
> 
> Diff: https://git.reviewboard.kde.org/r/127559/diff/
> 
> 
> Testing
> ---
> 
> Tested using financial statement from bug #360129.
> 
> 
> Thanks,
> 
> Łukasz Wojniłowicz
> 
>

Review Request 127556: Quit application if all windows were closed, refactor main()

[Christian David]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127556/
---

Review request for KMymoney and Cristian Oneț.


Repository: kmymoney


Description
---

Allow QApplication to quit if all windows were closed. Otherwise
KMyMoney would never shut down.

Used this commit for minor changes which simplify the code.

Most important is the removal of ```app.setQuitOnLastWindowClosed(false);```. 
Is there a reason why it was added?


Diffs
-

  kmymoney/kmymoney.cpp 0d0a317d753e9c48740180d13235163928687b2c 
  kmymoney/main.cpp cf77030aeb7de0f744bc2cf928514568d564e2e8 

Diff: https://git.reviewboard.kde.org/r/127556/diff/


Testing
---

Started and closed the app.


Thanks,

Christian David

[kmymoney] [Bug 361318] Setting reconciliation status fails if multi-selection includes scheduled transactions

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361318

--- Comment #2 from Christian David <christian-da...@web.de> ---
Maybe you have to be tricky: Create a normal transaction with a date which is
after the one of the scheduled transaction. Select the normal transaction and
click on an transaction which is above the scheduled one using a shift click.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 361318] New: Setting reconciliation status fails if multi-selection includes scheduled transactions

[Christian David via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361318

Bug ID: 361318
   Summary: Setting reconciliation status fails if multi-selection
includes scheduled transactions
   Product: kmymoney
   Version: unspecified
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: General
  Assignee: kmymoney-devel@kde.org
  Reporter: christian-da...@web.de

A useless error message is shown if "Mark transaction as…" was used on a
selection of multiple transactions in the ledger if the selection includes
scheduled transactions which were not entered, yet (“the grey ones”).

Reproducible: Always

Steps to Reproduce:
1. Mark multiple transactions in ledger, including a scheduled transaction
2. Context menu -> Mark transaction as… -> Select something

Actual Results:  
Warning dialog with useless error message "Error" and empty details

Expected Results:  
Hard to say how KMyMoney should react in this case. Minimum resolution should
be a better error message.

Using KMyMoney from branch frameworks 04/02/2016. I do not think we changed
anything here, so the issue is probably the same in the 4.x branch.

-- 
You are receiving this mail because:
You are the assignee for the bug.