I'm not too happy about more and more platform-specific code, but if this is really required, fine with me.

Please do move the implementation to guiutil, though.

You can use a typedef to give the new name to the original class on non-Mac platforms, so the application code can be free of platform-specifics.

I also don't like it.
But i like it more than useless burn cpu.
It would bring back the possibility of a AppNapping and a Network-Disabling-Switch (some people might do the same like i do and block bitcoin-qt traffic with soft-firewalls to prevent cpu/network-bandwidth while on the go).

Is there a patch ready from Qt upstream that could be used during the build? I know we already include some patches during build time.

@Diapolo i did search for a qt patch but could nothing found. I also followed the idea of writing a qt patch (root cause fixing) but didn't succeed.

I just think we owe the user a more or less bug free bitcoin-qt client. This pull does not follow a state of the art architecture but makes the enduser experience better.

I try now to move it to guiutil and try to follow sipa's advice with the typedefapproach

@sipa i just implemented typedef "switch". But IMO it more unclear then. I would recommend to keep it as it was with the #ifdef directly while instantiating the object. I think it is better understandable and the code is shorter.
What do you think?

I'll leave that up to @laanwj. I was just giving a suggestion on how you could keep the platform-dependence out of the application code.

Agree with @sipa; something like

#include <QProgressBar>
#ifdef Q_OS_MAC
#include <QEvent>

// workaround for Qt OSX Bug:
// https://bugreports.qt-project.org/browse/QTBUG-15631
// QProgressBar uses around 10% CPU even when app is in background
class ProgressBar : public QProgressBar
{
 bool event(QEvent *e) {
 return (e->type() != QEvent::StyleAnimationUpdate) ? QProgressBar::event(e) : false;
 }
};
#else
typedef QProgressBar ProgressBar;
#endif

Then in the code you can just do

progressBar = new GUIUtil::ProgressBar();

...would contain the platform specific code this to just guiutil.h. We just define our own progress bar class which happens to be different on a certain OS.

Okay. Now i see.
I just updated the pull.

Making all in src
CXX libbitcoin_util_a-clientversion.o
AR libbitcoin_util.a
CXX qt/qt_libbitcoinqt_a-bitcoingui.o
In file included from qt/bitcoingui.cpp:10:
./qt/guiutil.h:199:42: error: no member named 'StyleAnimationUpdate' in
'QEvent'
return (e->type() != QEvent::StyleAnimationUpdate) ? QProg...
~~~~~~~~^
1 error generated.
make[2]: *** [qt/qt_libbitcoinqt_a-bitcoingui.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Got this with current commit a574189

What version of Qt? Probably it needs a version check too.

Admin@MacBookPro-3:~/Desktop/test/bitcoin $ brew upgrade qt
Error: qt-4.8.6 already installed

OK - looks like this should be a Qt5-only workaround

Hmm.. Yes. The enum is only in qt5 available.
I will wrap it in a Qt5 #ifdef.

Thank you guys!