all three variables were unused ever since the code's introduction in
229a0de9c8 "CWS-TOOLING: integrate CWS
appleremote01"
Change-Id: Ib755b86c81a6823c440f9f6a392b8f4b7de973ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116984
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(That warning is probably new in recent Clang 10 trunk, hence the issue only got
reported now.)
To me, this looks like a bug introduced with
> commit aaf218d025
> Author: ericb2 <ericb2@apache.org>
> AuthorDate: Sun Oct 30 22:57:34 2011 +0000
> Commit: Thorsten Behrens <tbehrens@suse.com>
> CommitDate: Mon Dec 5 13:00:11 2011 +0100
>
> Propragating the modif in the implementation (HIDRemoteControlDevice.m)
>
> * found under MIT-style at svn rev 1195272 (http://svn.apache.org/viewvc?view=revision&revision=1195272)
>
> diff --git a/apple_remote/HIDRemoteControlDevice.m b/apple_remote/HIDRemoteControlDevice.m
> index 94215900717b..2cd7506e60d3 100644
> --- a/apple_remote/HIDRemoteControlDevice.m
> +++ b/apple_remote/HIDRemoteControlDevice.m
> @@ -281,7 +281,17 @@ - (void) handleEventWithCookieString: (NSString*) cookieString sumOfValues: (SIn
>
> NSNumber* buttonId = [[self cookieToButtonMapping] objectForKey: cookieString];
> if (buttonId != nil) {
> - [self sendRemoteButtonEvent: [buttonId intValue] pressedDown: (sumOfValues>0)];
> + switch ( (int)buttonId )
> + {
> + case kMetallicRemote2009ButtonPlay:
> + case kMetallicRemote2009ButtonMiddlePlay:
> + buttonId = [NSNumber numberWithInt:kRemoteButtonPlay];
> + break;
> + default:
> + break;
> + }
> + [self sendRemoteButtonEvent: [buttonId intValue] pressedDown: (sumOfValues>0)];
> +
> } else {
> // let's see if a number of events are stored in the cookie string. this does
> // happen when the main thread is too busy to handle all incoming events in time.
(which indeed appears to be a faithful copy of all the non-whitespace changes
made at the cited <http://svn.apache.org/viewvc?view=revision&revision=1195272>
"Propragating the modif in the implementation (HIDRemoteControlDevice.m)").
I assume that my fix here is what was originally intended, but I don't know how
to actually test this code (if it is still testable at all).
Change-Id: If8faa8e068c7d7dffb4677efdaa5896cf6fd4c0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89209
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Some .m/.mm files that still contained tabs instead of spaces have been
cleaned up with Emacs' untabify (and
apple_remote/source/HIDRemoteControlDevice.m needed further manual adaptions):
apple_remote/source/GlobalKeyboardDevice.m
apple_remote/source/HIDRemoteControlDevice.m
apple_remote/source/KeyspanFrontRowControl.m
apple_remote/source/RemoteControl.m
vcl/osx/a11yrolehelper.mm
* Some of the changes predate 0626e66d76 "Avoid
loplugin:indentation after preproc conditional inclusion lines" and would
likely have no longer been flagged since.
Change-Id: Ibf5faffa743c7f79b36109d9879eb79d63c8c40f
Reviewed-on: https://gerrit.libreoffice.org/68090
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
using autorelease here leads to “just leaking” because there's no autorelease pool for thread
besides, make sure that released fields do not contain used•to•be•a•valid•pointer value
Change-Id: Id6cb37643230f64dbe9f6128f52236f04d0c88e4
Reviewed-on: https://gerrit.libreoffice.org/22981
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
module appropriately
to make the source of some log messages more clear
(cherry picked from commit fe4ae4735c5a5e2b2210e684e97228cd91174e4c)
Conflicts:
apple_remote/AppleRemote.m
apple_remote/source/HIDRemoteControlDevice.m
apple_remote/source/RemoteControl.m
apple_remote/source/RemoteControlContainer.m
Change-Id: Ie57114f4d2d67f258808d03e01dff8bc05ba9f2c
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
When LibreOffice is compiled against the 10.6 SDK and run under gdb,
the apple_remote code caused "cannot init a class object" exception
messages to be printed.
Upon closer inspection this was caused by the call to [super init] in
the sendDistributedNotification class method of the RemoteControl
class.
As far as I understand, calling [super init] and assigning its return
value to self, even, is pointless and wrong in a class method.
This code apparently has not been causing any harm when built against
the 10.4 SDK. This is probably just accidental thanks to a more
lenient Objective-C runtime getting used?
When built against the 10.6 SDK, though, the resulting Objective-C
exception seemed to make input event handling non-functional. After
this fix LibreOffice built this way works better.
Change-Id: I I I383611753f3f83a9efa4694b1900c8b66ed1a8e3
Andrea Gelmini