In D12808#262242, @wojnilowicz wrote:

[…] so what's left is:

1. Untranslated excepctions, as normal user doesn't need to understand exceptions, only developers do,

I like this very much!

In D12808#261399, @wojnilowicz wrote:

I understand that it allows us to distinguish between exceptions but who should handle exceptions that we can't handle?
I think it's our duty to do that, because some library throws it at us, because we acted on it in some way, so we are here to blame, so we should handle it.
Just passing exception beyond our application doesn't make the issue go away.
In my opinion, we should know every exception that is being thrown at us, so that we can be aware, even if we aren't prepared from the outset for it.

Why was it disabled in the first place if the fix is that easy?

actually I liked the separate class for exception handling. It allows to distinguish between issues within KMyMoney and outside of it. Typically we do not/cannot handle things like std::bad_alloc so the “missing” catch is desired. Also there is some code which expects this behavior (I think the onlineJob casting stuff), just replacing everything is dangerous. You could inherit MyMoneyException from std::runtime_error. Then we can knowingly change the catches where it is useful and safe.

I am not into this code, so I can only give general advice.

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

In D11841#242724, @wojnilowicz wrote:

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

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.

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 found a new warning which is generated by this patch. However, I would leave it as it is, because there will be a warning or we may miss when a change to CMake 3.10 becomes mandatory.

Hi Thomas,

In D10164#198089, @wojnilowicz wrote:

If your questioning of krazy correctness will be accepted by krazy maintainer Allen Winter, then I am in for this patch.

The first two notes are not so important but the corresponding code should get a /**@todo */ comment.

In D10164#197474, @wojnilowicz wrote:

I have some questions for that:

1. As I see correctly, that brings us warning by our code checker krazy back. What for?

I saw once, that the OLD behavior may cause other warnings. However, I cannot reproduce this. Since I am not able to push currently, I will observe this and push later (to branch 5.0).

Reverted last change - I am fighting with arc :(

Corrected build location of checkprinting plugin

From my point of view, the only issue left is the line QCoreApplication::addLibraryPath(QCoreApplication::applicationDirPath() + QDir::separator() + "kmymoney-plugins");. Since this seems to be a highly emotional question so I do not think further discussions are of use here.

In D9710#187356, @wojnilowicz wrote:

[…]
Why do you want to eliminate installing? On my machine it takes like less than second and my machine isn't at any point fast.
Why is setting environment variable so upsetting? I've set it once and it isn't impacting my speed or my time.

Hi Olivier,

Hi! Did you do a performance comparison? I am concerned that this patch can reduce performance significantly because some of the objects are created very often and in huge amounts. Additionally we perform searches with them. Also I am not sure if these very simple objects (often POD) can really benefit from a d-pointer, except ABI stability. The drawback is increased code complexity.

Wow, this is an impressive huge amount of work.

In D8506#160529, @tbaumgart wrote:

This is not needed if you build out of source or the name of your build directory matches the first entry in .gitignore which is 'build*/'. On the other hand, it does not hurt either.

In D6384#119828, @tbaumgart wrote:

[…]
and using the proposed change does not work. Not sure if there is a newer version available and how I would install and not brake anything.

I am with Łukasz. If all developers can compile KMyMoney I am all in. I would not worry about the distros because until we can release this version this won't be an issue anymore.

Your changes improve the code a lot! They make this code better in so many ways, thank you!

In R261:398304bcf331a322a0fe7e475775aea887c4b565#1999886, @wojnilowicz wrote:

[…]

Hello Lukasz,

In D5655#105942, @wojnilowicz wrote:

I don't like this idea. In the moment there is no third part app to backup KMM, so there will be no backup feature at all.
Moreover I don't get why it must be third part app and not KMM.

In D4655#87283, @ostroffjh wrote:

Christian - I think the reason is in the original bug "... changes in e.g. investments with large different values are hardly to recognize on a linear scale (e.g. change of 20 to 10 if you have a graph changing from 150 to 70)." I'd probably like to see some actual examples of cases where it makes sense, but I don't see any reason against doing it.

Well this is not very convincing to me, whatever.

I am just curious, why should an app for private finance should have a logarithmic axis? This does not sound useful to me.