It seems to me that English texts will get better hyphenation if the system language in macOS is set to English. Thing is, it is hard to be sure, and restarting with a new system language is cumbersome, so I haven't tested this thoroughly, but I'm reasonable sure that I've only seen "somet-hing" and similar when my system was set to Swedish.
This is on macOS Big Sur, in an NSTextView with hyphenation switched on by setting hyphenationFactor to 1 on an NSParagraphStyle object in an NSAttributedString. It is not a web view. The application is not localized, so the app language is English even when the system is set to Swedish. Setting NSAccessibilityLanguageTextAttribute to "en-US" seems to have no effect.
I'd like to know if anyone can confirm this, and if so, can anything be done about it?
From the documentation of hyphenationFactor:
This property detects the user-selected language by examining the first item in preferredLanguages.
+[NSLocale preferredLanguages] is called once from -[NSAttributedString lineBreakByHyphenatingBeforeIndex:withinRange:] but before that the language is read from NSUserDefaults with key NSHyphenationLanguage. Setting the language with
[NSUserDefaults.standardUserDefaults setObject:#"en" forKey:#"NSHyphenationLanguage"]
seems to work but it is undocumented, so use it at your own risk.
Related
I have had this issue for a while, and now, after a fresh install of macOS I am plagued with it again, so, I am sure this isn't the result of some custom program running on the machine. I only have macOS Big Sur and IntelliJ IDEA (I had Catalina before with the same results).
Whenever I try to refactor code to introduce a new parameter using Command-Option-P, the preferences window pops up. This is beyond annoying, and I would rather not throw away years of muscle memory by remapping my extract parameter shortcut to something else.
Has anyone experienced this, and if so, what is the way to fix this?
Thanks to the comment by #CrazyCoder who looked into this.
This is a known issue with the "ABC - Extended" keyboard selection on the macOS. I like this keyboard for the range of optional characters it gives me. But apparently, there is a known issue that prevents correct behavior in this case: https://youtrack.jetbrains.com/issue/IDEA-242986
As yolu may have noticed, MS introduced a modern kind of 'theming' in Windows 10 regarding the basic OS elements like start menu and taskbar. With newer versions, you can choose a 'light' theme as an alternative to the default black theme.
I was wondering if there is an API or hook to elegantly and (more importantly) efficiently check live for theme changes (Did not find anything in the MS docs regarding this, but often enough these gems are pretty hidden there IMHO).
Specific problem: When you have a desktop application with a system tray icon, chances are high that you designed it to be bright. Nearly all of the modern Windows icons feature such a style (simple and white, yielding good readability on the black taskbar). Now you can provide a different version in a darker style for the light theme, but how to notice when to apply this on the fly?
I'm aware of the registry key under HCU (Software/Microsoft/Windows/CurrentVersion/Themes/Personalize) which is what I'm utilizing right now. However, blindly checking for change every x milliseconds seems pretty awkward.
If no such thing is available, I'm also happy to hear some ideas for more efficient implementations of such a check.
Method 1： Use RegNotifyChangeKeyValue
Notifies the caller about changes to the attributes or contents of a
specified registry key.
Methon 2: Use WM_SETTINGCHANGE
Applications should send WM_SETTINGCHANGE to all top-level windows when they make changes to system parameters. (This message cannot be sent directly to a window.) To send the WM_SETTINGCHANGE message to all top-level windows, use the SendMessageTimeout function with the hwnd parameter set to HWND_BROADCAST.
I tend to use the second method, I have tried, and have been able to work successfully.
Minimum code example：
case WM_SETTINGCHANGE:
{
if (!lstrcmp(LPCTSTR(lParam), L"ImmersiveColorSet"))
{
//theme has been changed
}
}
Our app has some non-rich-text NSTextViews that users can enter text into. When a user enters "..." into the text view, OS X automatically replaces it with an ellipsis character, which we don't want to happen. This needs to be something we disable for all users of our app, rather than relying on them to disable it themselves.
I expected this to be an NSUserDefaults setting, like the "ApplePressAndHoldEnabled" one, but I was unable to find anything in the docs about it. I found some information about the "WebAutomaticTextReplacementEnabled" preference that sounds like it does what we need, but setting it to "NO" doesn't seem to do anything for our app.
I've also looked at NSSpellChecker, which appears to provide the "isAutomaticTextReplacementEnabled" method to check whether text replacement happens, but no way to stop it happening for an application.
How can I disable this text replacement for our app?
There are settings in the nib file for this (select the NSTextView). Unfortunately as of the latest version of OS X / Xcode, some of them seem to be broken so you may find that you have to send messages to your view from e.g. -awakeFromNib instead, e.g.
- (void)awakeFromNib
{
[myTextView setAutomaticQuoteSubstitutionEnabled:NO];
[myTextView setAutomaticTextReplacementEnabled:NO];
}
See the documentation for NSTextView for the full set of methods.
I ran into a reproducible bug which doesn't really make sense to me. Hopefully someone knows more about the internals of keyboard input under Windows (I'm using Windows 7) and can point me in the right direction on how to solve it. As it stands now I don't really know where I should start to look.
My application creates a global keyboard hook, using the MouseKeyboardActivityMonitor library. This was working fine for me, but I quickly received bug reports from people using different keyboard input languages. When they write letters with accents, e.g. ë and ê, they show up as ¨¨e and ^^e respectively. This bug is also reported on the library's website, but hasn't been resolved yet.
To try to reproduce the bug I set up an alternate input language 'Dutch (Belgium)' next to my existing 'English (United States)'. After some toying around I discovered the following:
The bug doesn't occurs when the application which installs the hook has focus, and language is set to 'English (United States)'. Writing in any other application (e.g. notepad) and using 'Dutch (Belgium)' to write the special characters work. The bug does occur when the application which installs the hook has focus, and language is set to 'Dutch (Belgium)'.
I am looking for any clue as how the two are related. Perhaps I need to introduce some extra checks in the keyboard hook library? The source code of the keyboard hook is available on line.
It seems that the input language is not updated in your application. Looking at the source code of the library that you are using, it seems that they use this call to get the correct keyboard layout:
internal static extern uint GetKeyboardLayout( int dwLayout );
The documentation of this method however emphasises:
The input locale identifier is a broader concept than a keyboard
layout, since it can also encompass a speech-to-text converter, an
Input Method Editor (IME), or any other form of input. Since the
keyboard layout can be dynamically changed, applications that cache
information about the current keyboard layout should process the
WM_INPUTLANGCHANGE message to be informed of changes in the input
language.
However, based on a quick glance at the code, the library does not seem to respond to this WM_INPUTLANGCHANGE message, which might cause this behaviour
Also, here is a useful link to an explanation how the Keyboard is handled by Windows
Users of my application keep running into issues related to other applications declaring a different UTI for the same file extension as my application. I think I can best describe this with an example:
My application supports importing and exporting OPML files. For this to work I import the org.opm.opml UTI in my info.plist. This mostly works fine, but fails if an other application declares a different UTI for the opml file extension. For example com.redlex.opml or com.xwavesoft.cloudoutliner.opml.
Is there something I can do to work around this problem? Can I somehow tell launch services that my application accepts all files with an .opml extension?
I solved this issue with the following work around:
I removed the entire LSItemContentTypes entry from the list of CFBundleDocumentTypes
In my NSDocument subclass I use NSString's rangeOfString:: method to look for the #"opml" keyword in the typeName parameter.
This work around was confirmed by a user.
Cloud Outliner updated on the MAS today, and looking at the UTI for .opml files now, the com.xwavesoft.cloudoutliner.opml is now gone and com.redlex.opml is now in its place. Which would be uninteresting, except for the fact that OPML files now open in MindNode without a problem.
I can't find any release notes for Cloud Outliner other than "various fixes and improvements." but it would seem that something changed for the better. So: in my case - the simple answer was "update Cloud Outliner" but I'm not sure this solves the larger problem. I also have Mellel on my system (obviously, right?!) but this doesn't seem to be causing the same issue.
For those watching this thread - the issue presented as MindNode showing greyed-out icons for OPML files in its open dialog. Dragging OPML to the MindNode icon in the dock also produced no results.
Rob