How to get System Keyboard Shortcuts programmatically - cocoa-touch

I just developed an iOS 8 Custom Keyboard and my users are requesting to be able to import the Keyboard Shortcuts in System Settings.
Settings -> General -> Keyboard -> Shortcuts
I thought it was impossible because all apps run in sandbox and does not have access to System Settings. However, this custom keyboard did achieve this.
https://itunes.apple.com/cn/app/bai-du-shu-ru-fa-zui-kuai/id916139408?mt=8
It has an option to import Keyboard Shortcuts next time when custom keyboard loads.
Anyone has any idea which API is this?
Thanks.

From Apple's App Extension Programming Guide:
Every custom keyboard (independent of the value of its
RequestsOpenAccess key) has access to a basic autocorrection lexicon
through the UILexicon class. Make use of this class, along with a
lexicon of your own design, to provide suggestions and autocorrections
as users are entering text. The UILexicon object contains words from
various sources, including:
Unpaired first names and last names from the user’s Address Book database
Text shortcuts defined in the Settings > General > Keyboard > Shortcuts list
A common words dictionary
In particular pay attention to UILexicon's requestSupplementaryLexiconWithCompletion:
Call this method to obtain a UILexicon object containing a basic set
of term pairs for use in autocorrection or textual suggestions based
on user input. The UILexicon object contains words from various
sources, including:
Unpaired first names and last names from the user’s Address Book database
Text shortcuts defined in the Settings > General > Keyboard > Shortcuts list
A common words dictionary

Related

What is the principle by which keyboard shortcuts selected in IntelliJ IDEA?

There are lots of useful functions of Intellij IDEA and for many of them there are keyboard shortcuts.
But remembering shortcuts may be difficult, at least for me.
Are there some consistent guiding principles by which these shortcuts were selected by designers? I believe learning such principles would be helpful to memorize shortcuts itself.
I think that the closest answer you're going to get is "it depends". Some shortcuts are obviously chosen, because the keybinding describes what the shortcut does, for example ⌘+O means open, not only in IntelliJ but in many places throughout OS X.
Some shortcuts probably don't have any kind of such semantic meaning, such as Alt+Enter and are chosen because they are very frequently used and the placement of the keys relative to each other is comfortable.
Other keyboard shortcuts with similar purpose have the same starting sequence of keys. For instance the extract refactoring shortcuts, which are as follows:
⌘+Alt+M - extract method
⌘+Alt+C - extract constant
⌘+Alt+V - extract variable
⌘+Alt+F - extract field
⌘+Alt+P - extract parameter
So in such case you only need to remember that if you want to extract something, you press ⌘+Alt and the first letter of what you want to extract.
That being said, I don't believe that the way to learning the keybindings is memorizing them, but using them. If you use one keybinding multiple times, over the time you will memorize it. You can help this process for instance by locating the action you want to perform in the menu, but instead of clicking it look at the keyboard shortcut next to it and press it. Or find the action using ⌘+Shift+A, look at the shortcut and use it.
There are even plugins, which can help you with this, for instance Key Promoter which you can install via Settings/Plugins/Browse Repositories. This plugin shows you shortcut you can use when you invoke some actions by clicking it in menu, etc. It also shows you how many times you've used this action in such a way instead of using the corresponding shortcut.

How to automate or programmatically make changes to System Preference settings on Mac OS X

I am trying to figure out how to programmatically change System Preference settings on the Mac OS X. If that is not possible, create some post-installation automation script (using Apple Script or other means) and run it as part of the installer. I am particularly interested in making changes to the "Language & Text" settings which are part of the "personal" settings in System Preferences.
Here is more description of my problem:
I am trying to create an installer for a custom keyboard layout I wrote for Mac OS X. The keyboard layout basically allows people to transliterate ASCII keboard input to foreign letters. The foreign language does not exist on Mac OSX*. I was able to use Apple's PackageMaker to create a basic installer that dumps all the necessary files (.keylayout file, icons and the custom fonts) in their respective directories in the target computer. But there are a couple of personal settings that need to be configured in System Preferences before the keyboard layout can be selected and used. I would like to auto-configure these "one-time" settings for the user during the installation process. Is it possible to make changes to the settings using Cocoa/Objective-C. If not, I would like your help on how I can use Apple Script to automate the configuration. Please include some sample code or pointers to examples if possible. Thank you.
Here are the settings that need to be configured on System Preferences
Select System Preferences --> Language & Text -- Input Sources
Select "The Language Name" from the list
Click on "Keyboard Shortcuts" and enable "Select the previous input source" and "Select next source in Input Menu".
Double click on the shortcut combinations "⌘ space" and change them to "⌘ L" for the "Select the previous input source" and "ctrl⌘L" for "Select next source in Input Menu"
Exit systems preference. Done
NB: *The system language need not be changed. Only the input source (keyboard layout).
See NSUserDefaults. The values you want to set are probably in NSGlobalDomain.

Get key used to change Spaces

Is there any way to programatically determine what key is set in System Preferences to change to a specific Space.
This setting is configured in the Expose & Spaces preference, under the Spaces tab. The last drop down box is titled "To switch directly to a space" and you can choose from the control key, the command key, the option key or no key.
This is the value I'd like to programatically determine.
Possible?
You could try using AppleScript's GUI scripting to programatically open the preferences pane and see what is in the drop down box. An example is here. To invoke it from Objective-C, check out Scripting Bridge if you're using OS 10.5 or later, otherwise there's an older API but I can't seem to find it at the moment.
If you want a solution that doesn't require popping up the System Preferences window and showing all its animations to the user, the actual value is stored somewhere in ~/Library/Preferences/com.apple.symbolichotkeys.plist, but the format is not human-readable. You could change the key binding from System Preferences and compare that file before and after. Keep in mind that this may be different between versions of OS X.
Hope this helps, and welcome to Stack Overflow!

Options, Settings, Properties, Configuration, Preferences — when and why?

There are several words with similar (in some sense) meaning:
Options, Settings, Properties, Configuration, Preferences
English is not my native language. Could you explain the difference in simple English please? I think the following template could be useful:
Use XXX in your GUI in order to let people change behaviour of your application (maybe preferences or settings?)
Use YYY in your GUI in order to let people change parts of an object (perhaps properties or options?)
Use ZZZ in your code ...
What are best practices?
Tricky, this, as there's no one single consistent style followed by all applications. As you say they are (broadly) synonyms.
In truth it doesn't really matter so long as your expected audience understands what you mean.
The biggest difference is between Properties, which usually affect a component or object, and the others, which affect the whole application.
Following an approximate lead from Visual Studio and other Microsoft products:
Properties represent the characteristics of a single component or object in the application.
Options alter global ways that the application works. Microsoft products use this to customise the UI toolbar, for example. There's an implication here that you can disable UI elements altogether (e.g. a "Simple" user interface or an "Advanced" user interface).
Settings and Preferences change qualities of how the application works. The implication here is to change, not disable: for example, "Metric measurements" or "British Imperial measurements".
Configuration is often where an application is customised for each user or group.
But there's no single rule.
I'd suggest you use Properties for object characteristics and Settings for everything else that's application-wide.
These aren't set anywhere, but I figured I might as well chip in my 2¢ on the topic. When I see these in an application, this is what they imply to me:
Settings: "View or modify the list of things that can be set"
Options: "We have set some things already, and give you the option to change them"
Preferences: "Tell us how you prefer this to work"
Properties: "Change one or more properties of this item"
Edit: "This thing is already in a good state, but you can change it if you like"
Configuration: "We have defaults, but they're so barebones you probably want to configure it yourself"
I just did a quick scan and wanted to post this list for reference.
Edge Settings
Google Chrome Settings
Google Chrome DevTools Settings > Preferences
Mozilla FireFox Options (about:preferences) > Network Settings
Mozilla FireFox DevTools Settings > Editor Preferences
Opera Settings
DeviantArt Settings
Facebook Settings, News Feed Preferences
GitHub Settings
Google Settings
IMDb Account Settings > Preferences
Instagram Options (aria-label)
JSFiddle Settings
StackOverflow Settings > Preferences
Twitter Settings
YouTube Settings
FileZilla Edit > Settings
GitHub File > Options
Notepad++ Settings > Preferences
VS Code Preferences > Settings
Audacity Preferences
IcoFx Options > Preferences > Options
Process Explorer Options
TeamViewer Tools > Options
uTorrent Options > Preferences
Windows Media Player Tools/Organize > Options
phpmyadmin Settings
XAMPP Config > Service and Port Settings
> Log Options
MS Word File > Options > Proofing > AutoCorrect Options
> Writing Style Settings
Photoshop Edit > Color Settings
Edit > Preferences
Type > Language Options
3D > 3D Print Settings
Viev > 32-bit Preview Options
Window > Options
Windows Settings
Used as the parent (window/choice):
Settings : 20 times
Options : 10 times
Preferences : 4 times
Config(uration) : 1 time
Total mentions:
Settings : 24
Options : 15
Preferences : 12
Config(uration) : 1
Based on this, I'd sort these in this order (from general/fixed/app-related to specific/dynamic/user-related):
Settings > Options > Preferences
I think that one point of view is missing here namely the relation between configuration/settings/options/preferences.
To me a configuration or preferences contain many settings or options so there can be one setting or one option.
You usually say "Change this option/setting" and not "Change this preference/configuration", don't you?
When someone says preferences or configuration I understand it as a set of settings or options.
One thing that I don't see in the answers here (although bobince alludes to it) is that you should consider what is typical for your environment/operating system. For instance on windows I think "Options" is the most common choice even though many programs use different words. Likewise "Preferences" for mac os. Android OS uses "Settings"
So bottom line, use what is most common for your environment.
I believe it's largely a matter of personal preference.
However, I feel that I usually see properties as referencing one single part of an appliation, where as Options/Settings are usually a more global property.
In addition, Preferences are probably not things that have as large of an impact as something labeled options or settings. Things such as a minor change in the display or something similar.
The most important thing is to have consistency across the application.
And personally, I prefer the term 'options', as it sounds less intimidating than settings, properties, or configuration.
Apart from Properties (which usually applies to a document or object inside a document, except when it doesn't), they're pretty much all the same. No-one agrees which terminology is best.
For example for program config, Apple style is ‘Preferences’ in the application menu, GNOME style is ‘Preferences’ on the ‘Edit’ menu. KDE style is a whole ‘Settings’ menu of its own. Windows style was ‘Options’ on the ‘Tools’ menu, though all bets are off now as more MS apps drop the menu bar and throw the old predictable controls all over the place with no consistent pettern.
RISC OS style was ‘Choices’ on the icon bar menu, just to add yet another pointless possibility.
Options: usually for components or objects. You have right to choose, so there're some options for you to choose.
Settings: There's a system. It may work as it always do, but it offers some settings for you to adjust its behaviors.
Properties: every object has properties. color, size, and etc. You 'set' settings. and you 'change' object's properties.
Configuration: usually, every system has its configurations, either a default one or a customized one. The system needs a proper configuration in order to run properly. Usually, it has little meaning of user's choice or not. Although you can adjust system's behavior with different configurations.
Preferences: you may prefer a different habit, so here comes the prefer-ences. Every user may have their own habits. Preferences is more like different users sets of prefers. In system level, it may work via different configurations, but on the GUI, we don't say configuration, we say preferences.
In conclusion, for example, in a drawing application, you may say, we change the properties of a circle, a shape. When you start the application, we have three options to choose for how the application would appear after launch. There are some configuration files under the installation folder, some may easy to understand, but some may be very technical, which is not prepared for normal users. Users they just change settings in the menu, to decide how a function works in the application. Settings and Preferences usually don't appear in the same application. Tools that more for efficiency, use Settings more. Applications that more for conveniency, use Preferences would be more friendly for users.
Hope those help.
Settings: Thinking of a slider to select a value from 1 to 10 for example
Options: Thinking of an on/off button
Preferences: Thinking of a choice from multiple choices, like morning, afternoon or evening
Configuration: Technical settings probably end users should not know about. Like what is the data source?

Specifying the Order of Start Menu Shortcuts

I created shortcuts for some of my exe's in the program menu. For example, I might create shortcuts for a.exe, v.exe, and g.exe. By default, it aligns as a, g, v (in alphabetical order). I want to place my shortcuts in a different order, such as (v, a, g).
In short, I want to be able to change the order for the shortcuts it creates to something other than alphabetical order.
I am using wshshellobject in vb. I created a dll; through that I created my shortcuts
Assuming you're trying to modify the order of your shortcuts on the Start Menu, I'm not sure this is possible to do programatically (which is a shame - I've fired up the uninstallers for many apps in Vista/7 by typing their names and just hitting without looking!).
Microsoft's Raymond Chen posted this on his blog some time ago:
The classic Start menu and the "All
Programs" portion of the Windows XP
Start menu permit you to customize the
order of the shortcuts that appear
there. You can use drag/drop to
rearrange them, or force them to be
sorted by name. But why is there no
programmatic interface to these
actions?
Because the power would be used for
evil far more than it would be used
for good.
More info here:
http://blogs.msdn.com/b/oldnewthing/archive/2006/06/19/636823.aspx