In D12737#259095, @tbaumgart wrote:

Running this with

g++-6 (SUSE Linux) 6.2.1 20160826 [gcc-6-branch revision 239773]

produces a whole bunch of different (and useful as far as I have seen) warnings. And yes, I use DebugKMM, Debugfull or Profile from time to time (mostly Debugfull) so they should stay.

Running this with

Hi ocoole,

Hello, Łukasz. I've come back with my little test results.

Pushed, because next patch solved remaining issues.

Hi wojnilowicz , thanks for your comments!

It should pass on all platforms now (I've only tested it on Windows, which I'm using; it should (continue to) pass on other platforms too (if I didn't accidentally break it—but CI will tell))

Thanks Thomas!

The problem regarding the duplicate existence of the model seem to be solved. The following now does not work anymore. I have no idea how hard it would be to fix it.

I'll take care of landing it now.

Thanks a lot, Thomas. Didn't think of doxygen before, so thanks for pointing that out! (actually it's my first time heard of it, I probably should check that out),

I was about to land it but found these two little nitpicks in your todo entries. I also updated the summary which should address the link to the bug entry.

onlinejobmodel is used only by online job outbox plugin (and was moved there), so sharing of models can be avoided for now. Issue with jobs not appearing in the view was caused by not loaded view's model. Loading and unloading of the model is managed by KMyMoneyView.

Thanks Chris!
I don't think I have permission to push, but that's okay, I think it can wait before it's committed to the codebase.

Did not test, but looks good! Can you push yourself?

Thank you for reviewing the patch, @christiand.
(Sorry for the newbie mistakes.)
I've updated the diff according to your comments.

Custom icons for accounts
don't store icons in database as discussed in review.

In D11841#243384, @christiand wrote:

In D11841#242724, @wojnilowicz wrote:

I don't like it. Dynamic plugins offer me separation of code, build and run speed.

Static plugins offer the exact same amount of code separation as dynamic plugins. They are probably even faster at runtime and I am sure they do not change build time notably.

In D11841#242724, @wojnilowicz wrote:

I don't like it. Dynamic plugins offer me separation of code, build and run speed.

In D11841#242389, @christiand wrote:

In D11841#242049, @wojnilowicz wrote:

I don't know this problem, because I don't use this view. I think that packaging error is not our business. I think the view should contain more of online job bits but for know it's all that's easy to separate from the rest.

Which bits do you mean?

In D11841#242049, @wojnilowicz wrote:

I don't know this problem, because I don't use this view. I think that packaging error is not our business. I think the view should contain more of online job bits but for know it's all that's easy to separate from the rest.

In D11841#241787, @christiand wrote:

I want to raise a usability concern. If the user is using the online banking and this page gets disabled (e.g. accidentally, packaging error, some other error) KMyMoney still offers to queue transactions. However, without this plugin the transaction seems to be lost. Queued transactions are also kept during restarts. This could lead to further trouble if the queue is sent after the user forgot about the (hidden) transaction(s).

I want to raise a usability concern. If the user is using the online banking and this page gets disabled (e.g. accidentally, packaging error, some other error) KMyMoney still offers to queue transactions. However, without this plugin the transaction seems to be lost. Queued transactions are also kept during restarts. This could lead to further trouble if the queue is sent after the user forgot about the (hidden) transaction(s).

In D11841#240567, @tbaumgart wrote:

I analyzed this a bit. The problem is that there are two different objects of type Models::instance()->onlineJobsModel() since the libmodels library is static. One lives with the kmymoney object and contains the data, the other one lives with the now separated view and is empty. The models library therefor needs to be converted into a shared object and then things should work (like with the settings library). @wojnilowicz: can you take care of the conversion as part of this patch?

I analyzed this a bit. The problem is that there are two different objects of type Models::instance()->onlineJobsModel() since the libmodels library is static. One lives with the kmymoney object and contains the data, the other one lives with the now separated view and is empty. The models library therefor needs to be converted into a shared object and then things should work (like with the settings library). @wojnilowicz: can you take care of the conversion as part of this patch?

Existing jobs (persistent in the file) are not shown in the view after load of file and selecting the view. In case you need help to investigate please let me know.

Looks OK to me, though the patch did not cleanly apply to current master.

In D11805#237669, @habacker wrote:

According to kdelibs style (https://community.kde.org/Policies/Kdelibs_Coding_Style), which is derived from Qt style, constructor initializers are formatted with ',' as suffix, not as prefix. You may run the astyle command at the mentioned page to see this.

According to kdelibs style (https://community.kde.org/Policies/Kdelibs_Coding_Style), which is derived from Qt style, constructor initializers are formatted with ',' as suffix, not as prefix. You may run the astyle command at the mentioned page to see this.

In D11833#237563, @tbaumgart wrote:

Also, you should add a reports/.krazy file to avoid krazy complaints about the empty .kcfg file. See forecast/.krazy as reference.

Works for me with the following patch applied:

Otherwise, it works for me.

Some fixes according to comments.

Compiling this patch, I get the following warnings (I think I mentioned the result one already):

Looks good to me.

Sure thing (it's done using the Change Project Tags action from the action menu for future reference)

Enabled KBanking compilation.

Incorporated most of the suggestions.

I needed to add the following patch to get the kbanking plugin compiled and installed even though it was detected as enabled:

Generally it looks good to me though.

Works for me now. I did not find any anomalies.

No crash this time.

Select payees view, select payee with transactions, select transaction tab of that payee, double click on a transaction -> crash

Looks good to me.

Looks good to me. I'll take care of adding it to the repo.

add color coding of pos/neg amounts for 'posted value' column

Works for me

I added a knowledgeable reviewer. Maybe, he can share some of his wisdom.