Jul 5 2018
Jun 10 2018
May 16 2018
[…] so what's left is:
- Untranslated excepctions, as normal user doesn't need to understand exceptions, only developers do,
May 13 2018
May 12 2018
I like this very much!
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.
Apr 22 2018
Did not test, but looks good! Can you push yourself?
Apr 21 2018
Apr 9 2018
I don't like it. Dynamic plugins offer me separation of code, build and run speed.
Apr 8 2018
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.
Apr 7 2018
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).
Mar 26 2018
Feb 4 2018
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.
Feb 3 2018
Jan 30 2018
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.
Jan 29 2018
I have some questions for that:
- As I see correctly, that brings us warning by our code checker krazy back. What for?
Jan 28 2018
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
Jan 10 2018
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.
Jan 9 2018
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.
Jan 7 2018
Jan 5 2018
Jan 3 2018
Dec 3 2017
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.
Nov 5 2017
Wow, this is an impressive huge amount of work.
Oct 29 2017
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.
Sep 17 2017
Jun 29 2017
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.
Jun 26 2017
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.
Jun 19 2017
Your changes improve the code a lot! They make this code better in so many ways, thank you!
Jun 1 2017
May 31 2017
Apr 29 2017
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.
Apr 26 2017
Apr 23 2017
Apr 18 2017
Feb 18 2017
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.
Feb 17 2017
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.