Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indentation cleanup #142

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from
Open

Indentation cleanup #142

wants to merge 4 commits into from

Conversation

JanX2
Copy link

@JanX2 JanX2 commented Dec 30, 2021

I think I caught the last remaining tab character.

Kentzo and others added 3 commits June 28, 2021 23:21
Improved localization across languages to match macOS localization, with special focus on Simplified and Traditional Chinese
@JanX2 JanX2 changed the base branch from master to develop December 30, 2021 13:50
@Kentzo
Copy link
Owner

Kentzo commented Dec 30, 2021

@JanX2 Ah, When saw in my email I first thought about some edge-case key combination on rare locale with some mysterious input method :) Happy NYE!

@JanX2
Copy link
Author

JanX2 commented Dec 31, 2021

@Kentzo
Thank you! To you and yours as well.

A bit off topic: I’m still trying to figure out how to do menu item shortcuts with the recent versions. Do you have any pointers? Any code that does this? I keep running into issues with bindings that I can’t seem to be able to figure out.

This is what I’ve been doing with the 2017 version of the framework:
https://github.com/JanX2/Play/blob/64-bit-prep/Preferences/HotKeyPreferencesController.m
https://github.com/JanX2/Play/blob/64-bit-prep/Application/PlayApplicationDelegate.m
https://github.com/JanX2/Play/blob/64-bit-prep/English.lproj/HotKeyPreferences.xib

One of my main issues currently is that the new persistence format in defaults is different and I need to find a way to bridge the old format to new somehow. When a user launches the a new version of the app for the first time there are crashes/exceptions due to this.

The other is how to properly bind the customized shortcut and set it on a menu item.

Also there are a great many API changes and sometimes the behavior has changed as well.

From the git history I have understood that -pausesGlobalShortcutMonitorWhileRecording is now the default behavior. So we don’t need to do that manually anymore.

SRValidatorDelegate -> SRShortcutValidatorDelegate
flags unsigned int -> NSEventModifierFlags
SRValidator -> SRShortcutValidator
shortcutRecorder:… -> recorderControl:…
key code unsigned short -> SRKeyCode
shortcut taken… -> shortcut valid with inversion of meaning of boolean value

Additionally, it looks like, as of macOS 10.14, this is now the correct transformer for the bindings to defaults: NSSecureUnarchiveFromData. So the binding options should probably look something like this:

NSDictionary *options;
if (@available(macOS 10.14, *)) {
	options = @{NSValueTransformerNameBindingOption: NSSecureUnarchiveFromDataTransformerName};
} else {
	options = @{NSValueTransformerNameBindingOption: NSKeyedUnarchiveFromDataTransformerName};
}

@Kentzo
Copy link
Owner

Kentzo commented Jan 5, 2022

One of my main issues currently is that the new persistence format in defaults is different and I need to find a way to bridge the old format to new somehow.

Do you mean old-style dictionary vs SRShortcut?

You should be able to bind old-style dictionary to SRRecorderControl and it should just work in the compatibility mode. SRKeyEquivalentTransformer and SRKeyEquivalentModifierMaskTransformer (the ones you should use when binding Cocoa's keyEquivalents <-> NSUserDefaults) should be able to read and transform old-style serialized dictionary as well.

The other is how to properly bind the customized shortcut and set it on a menu item.

I suggest to migrate values in defaults to new SRShortcut some time very early in your app (before bindings are set up). The same transformers should be used for Cocoa Bindings

From the git history I have understood that -pausesGlobalShortcutMonitorWhileRecording is now the default behavior. So we don’t need to do that manually anymore.

Yup.

Additionally, it looks like, as of macOS 10.14, this is now the correct transformer for the bindings to defaults: NSSecureUnarchiveFromData.

Seems reasonable. Could you add a test to the suite that verifies that data previously written via NSKeyedUnarchiveFromDataTransformerName can be read via NSSecureUnarchiveFromDataTransformerName and vice versa?

IIRC if you specify options as nil, the appropriate transformation (keyed or keyed secure) will be done by NSUserDefaultsController regardless. You can verify that by putting a breakpoint inside SRShortcut's -initWithCoder: and -encodeWithCoder: and inspecting the passed object.

Also there are a great many API changes and sometimes the behavior has changed as well.

Let me know what workflow you need help with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants