Theme will eventually be moved to the GUI
Theme::appNameGUI and QApplicaiton::applicationName are the same, it is currently
set in the constructor of ConfigFile
This uses the new official API to show overlay icons and add our
custom context menu entry instead of hooking directly into the
Finder process and intercept drawind routines.
A dummy desktopclient target is also in the project to allow debugging
directly in Xcode while the official client can be started from the
command line. Otherwise Xcode won't allow attaching to the debugee.
Dummy icon files have been added while we get proper icon produced.
We can't use the old icons since what we use for the legacy shell
integration is already padded according to where the badge should
appear on the full icon.
This prepares the switch to the official FinderSync API on Yosemite
which requires the extension to run in a sandbox. This complicates
the usage of a local socket to communicate with a non-sandboxed GUI
client. An NSConnection is easier to use in this case, which we can
use as long as the server name (i.e. Mach port registered name) is
prefixed with the code signing Team Identifier.
A placeholder server implementation is also added to the client's
SocketApi which basically reproduces the interface of a QLocalSocket.
Most of the references to individual sockets we're only using
QIODevice methods so the type was simply reduced. A typedef to
replace the QLocalServer was the only other part needed.
Since our DLLs version number aren't bumped, a same file size could
cause a DLL not to be installed to replace an old one.
This eventually can cause a crash of explorer if an incompatible version
of OCUtil.dll is installed alone.
Fix the issue by defining LIBRARY_IGNORE_VERSION. This also makes sure
that installing an old version of the client over a more recent one
if we decide to add version numbers to those DLLs.
All things pushed to the "coverity_scan" branch will now get build by Travis and the resulting binary is pushed to Coverity and analyzed automatically.
Since Coverity has a fair usage policy which allows us up to 8 builds per week with a maximum of 2 builds per day we cannot run this automatedly on every push. Which also doesn't make that much sense.
Currently this can be used by reating a "coverity_scan" branch and force-pushing the new code to analyze. If all went well the Travis build should pass and Coverity should display the new information (give it some time to process the build though). In Coverity the SHA of the processed build will be used as version number as well as descriptive text.
(we can automate this though in the future as well if we want that too)
This will fail at the moment on master since Qt4 builds are failing as per https://ci.owncloud.org/job/client-build-matrix-linux/ - probably something that should get fixed. 1.8 branch worked fine though.
