to AppleRemoteController
having a MainController class in the global namespace of an application with
gazillions of MVC patterns is not a good idea. Renaming it to better match
its scope (i.e. the Apple Remote) cleans this up.
(cherry picked from commit 8ef3836059ca613d125f66e6bad21c83200dadad)
Conflicts:
apple_remote/source/RemoteMainController.m
include/apple_remote/RemoteMainController.h
vcl/inc/osx/saldata.hxx
vcl/osx/saldata.cxx
vcl/osx/salinst.cxx
vcl/osx/vclnsapp.mm
Change-Id: I1f252ac51ef65966a48ee03b2cd3519f98d57383
...post 68e2a4e41d "Revert 'Visibility doesn't
seem to work as we want in Apple's Clang.'"
Quoting <https://developer.apple.com/library/mac/documentation/developertools/
Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html> section "Symbol
Visibility and Objective-C:" "When building for x86_64 OS X or for iOS, symbol
visibility /does/ affect objective-C classes. [...] This means that if a given
class is intended to be usable outside the library or executable it's defined
in, you need to ensure proper symbol visibility."
The chosen syntax works at least with both --en/disable-64-bit "experimental"
(Clang-based) builds on OS X 10.8. Hopefully, it also works for baseline
builds. (Also, it could be that a more fine grained use of
SAL_DLLPUBLIC_EXPORT/SAL_DLLPRIVATE would be useful, but with the current setup
at least linking of Library_vcl against Library_AppleRemote works.)
Change-Id: Iff4fe9e50d1400c83879f62fe29b35bd19d58eb8
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
Philipp Hofer