Consistent labeling of physical keyboard keys... is it possible? - input

I have found that the Windows VK_OEM_X values have a tendency to refer to different physical keys, which makes them useless for localization-agnostic game controls.
I am thinking about using scan codes directly by hard-coding them, but that is my last resort.
Is there any other way to reference the physical keys on a 101-key* keyboard using Windows?
edit I also have need to work with far-eastern keyboards, which have the extra buttons next to the space bar.
For example: If I want the '/' key in my source code, I could be referring to the '!' key on a French keyboard. I don't care about what is actually printed on the key itself, nor am I trying to convert key sequences to characters. I am just looking for a standard labeling system that does not require a massive library of scan codes for different keyboards, let alone detecting the type of keyboard being used.

I don't think so. If anyone knows for sure, it is probably the author of this series.
Let the user's control the key bindings, default them for whatever 3 keyboards your users use most commonly, and prompt otherwise?

Related

Implement multi-column sorting in NSTableView

I want my NSTableView(s) to allow users to select multiple columns for sorting. I have the default sorting behavior working just fine, but I want the user to be able to click on a primary column header to establish the primary sort order, and then Shift, Option, or Command click on a secondary column header(s) to define sub-sorting.
This seems like a no-brainer, and I would have sworn that I've seen scores of apps that implement this, but hours of searching and reading Apple's documentation has found me no closer to a solution.
I suspect a solution can be implemented using the table delegate method -tableView:didClickTableColumn: (and possibly -tableView:mouseDownInHeaderOfTableColumn:). My idea is to catch this message, examine the currentEvent and, if the appropriate modifier key is being held down, undo the effects of the last -tableView:sortDescriptorsDidChange: message and reorder the sort descriptors into the desired order.
I also want the column header sort indicators to draw accordingly. I suspect that I'll need to do something about NSTableHeaderCell's -drawSortIndicatorWithFrame:inView:ascending:priority: method. What perplexes me about that one is I can find no place where the sort indicator state for a column is maintained (or at least accessible using the standard APIs). So I guess I'll have to subclass NSTableColumn or NSTableHeaderCell and provide my own state. The other thing that confuses me is that the header draw method clearly seems to support a "priority" parameter for multi-key sorting, but I can find nothing in the table column or view classes that let you specify this.
Anyway, if anyone has experience doing this I'd appreciate any feedback, suggestions, techniques, known pitfalls, etc. that you might have. (sample code would not go unappreciated)

Displaying Korean Characters - iOS App

I am trying to display Korean text in my iPhone app. The app appends the Unicode of letters one by one to an NSMutableString and displays the string on the screen after each letter is appended.
I understand that there are some rules for conjoining letters (Jamo).
Is there a function for automatically applying all these rules to a string of letters or do I need to write code to make changes (e.g., changing a consonant to a tail consonant if there is a vowel before it)?
FCA. It's you who sent email to me, right? Because the more detailed question is here, I will try (my best) to answer here instead of replying to your email.
By reading the whole text you and people wrote here, I figured out that you are making a Korean handwriting recognition software. So, you would not enjoy the luxury of the Korean input method provided by Apple.
There are two things for me to say. Let's go one by one. (I believe you are already aware of one of the two things I'm going to explain.)
How to compose Hangul text.
So, by reading your inquiry, it should not be about Unicode composed/decomposed Korean string (or just a series of Ja (Consonants) and Mo (Vowels)). Your question looks to be about "how to determine if a consonant (your term is tail consonant, right?) a user writes is a last consonant or the begining consonant of next syllable.
Best thing is to learn Korean, but let me briefly explain it.
Let's say you write 소방차 (a Fire dept. car.)
You are to write : ㅅㅗㅂㅏㅇㅊㅏ
(Again I'm not talking about the decomposed form of Unicode. It's about how people write Korean text.)
When you type ㅗ (which is the 2nd char) temporarily a display system displays 소 by attaching the ㅗ to its preceding ㅅ. And it will look up Korean table. (Although how to assemble Hangul is JoHap style (조합형), which is called composite style, there are tables of allowed Korean text defined in any Korean standard called Wansung style (완성형). So, you are to test the "assembled" syllable to the table to see if there is such a syllable). Then you will find "소" in the table. So, you will display "소".
Now the next char, "ㅂ" is written. Then here it becomes a little complicated. Because there is a syllable "솝" in the table, first it will attach ㅂ to the preceding syllable. So, it will display "솝". However, things are not determined yet completely. A user writes the next char, "ㅏ". It's pretty sure that there is no syllable without first/beginning consonant (Ja). It will look up the table, but fail to find a syllable "ㅏ".
So, it will guess the ㅂ (edited from ㅅ. it was typo) attached to the previous syllable actually belongs to the 2nd syllable. And it should display "소바". Now, ㅇ is typed. Then it tries to attach the ㅇ to the second syllable. So it displays 소방. (At this moment it can also lookup 방 in the table. And it is found.)
Now, "ㅊ" is typed. Probably internally it can test 소방ㅊ where o and ㅊ exist under 바 (I can't write it, because there is no such syllable with o and ㅊ exist together under 바, like 밝.). However, there is no such syllable. So, it instantly determines that ㅊ belongs to the next syllable.
Then "ㅏ" is typed. It will assemble ㅊ and ㅏ to make 차. When you press the space key or return key or any other white space key, it will finish composing Hangul.
This is a simple case. In Korean, there are more complicated syllables like 빨, 꼭, 헗, etc. For the first consonants, 복자음 (BokJaUm, Double Consonants) like ㅃ, ㄲ in 빨 and 꼭, people type ㅂ and ㅅ by pressing the shift key. Then it will display ㅃ and ㄲ. So, picking up how may consonants and determine where (previous syllable or next syllable) it belongs to can be easy if a user type with keyboard. (However, there are some nice Korean input methods for Windows and Xterm, where it allows to type ㅂ twice to make ㅃ. It's kind of an intelligent feature. But testing text like 빱빠라빱, 흙을 can be complicated because you end up testing 3 or 4 consonants grouped like {1,3}, {2,2}, {3, 1}.
The bad news is... because you are writing handwriting recognition, you may need to handle such complicated case if you input recognized Hangul characters one by one into a Korean input method engine. However, if you write up your own input method in your app, you can maintain its own state machine, so it can be easier. But as you can see, it's a trade off. Depending on the existing input method engine and ingesting each char into it. (Hmmm... wait... Maybe the input method engine can handle those complicated cases too.)
FYI, I would like to introduce two open source projects. One is a Korean input method Finder module for Mac, and the other is an input method engine with which you can make a Korean input method. Also, there is a Korean input method for X-Windows hosted here. If you prefer Windows project to look up, here is one.
The latter two were hosted at KLDP.net, a Korean open source project hosting site, but they were moved to Google code. As far as I can remember, "SaeNaRu" and "Nabi" (butterfly) can support typing the same consonant twice to make a double consonant.
For more detailed information, you can look up the libhangul and nabi. (I remember that the input method part of code was almost the same between libhangul and nabi before. But at that time they were separated and expected to evolve independently. So, I guess that they are different.
OK. The first thing is done.
Now let's move on to the second issue. (This is the part I said you may know about already. But just to complete my explanation, let me explain this also.)
It's about what character to choose as an input to your probable Korean input method state machine or a engine like libhangul. There are basically two representation of composed (on display) Hangul characters : Composed and Decomposed. Composed one contains fully composed chars. For example, 사랑합니다, each syllable, 사, 랑, 합, 니, 다 is saved as such. They are not stored as ㅅ, ㅏ, ㄹ, ㅏ, ㅇ, ㅎ, ㅏ, ㅂ, ㄴ, ㅣ, ㄷ, ㅏ.
That is composed representation in Unicode. This representation is usually used by text editors, etc. The other representation is decomposed in Unicode. It's like ㅅ, ㅏ, ㄹ, ㅏ, ㅇ, ㅎ, ㅏ, ㅂ, ㄴ, ㅣ, ㄷ, ㅏ.
This representation is usually used by file systems. For example, if you put a file name in Hangul on Windows, and access the folder which contains it from Mac, it will be displayed like ㅅㅏㄹㅏㅇㅎㅏㅂㄴㅣㄷㅏ although it is displayed as 사랑합니다 on Windows.
However, there is another set of characters if memory serves, which is just a list of Hangul consonants and vowels. Although they may look same or similar to decomposed syllables, they are actually different in that the location where they are drawn is in middle a space where a character is drawn. Its purpose is to present Hangul characters in Korean alphabet tables or things like that for education purpose (or any other purpose.)
So, I'm not sure what characters (i.e. the decomposed or the characters for the list of Hangul consonants and vowels) to ingest to a input method state machine or input method engine you choose or implement. If you implement it, its your choice, but if you use some external libraries for the engine, you need to figure it out.
Also, as I mentioned in my blog post, there are two variants in each composed and decomposed representation, which are all defined in Unicode standard. So, well.. yeah.. I agree. It's quite a bit of work.
As for me, I tried to make an input method for Mac, (when Apple announced they would get rid of the Finder plugin architecture for security issue), but at that time libhangul (Yeah.. I tried to use it) was being changed a lot. So, until it stabilized, I decided to hold off. But because I became very busy at work and tired when I got home, so I didn't make progress on my own input method. So, I believe the state of the libhangul project is much better now than ever. So, it's good try at least to take a look at it.
Also, if you don't have Windows, it would be good to try hanterm or any xterm derivatives which supports Hangul input in itself. The source code will be available at their hosting web site.
Good luck with your project, and if there are more things to ask me, please do so.
Check out these system level text-input facility. I never used these, but looks promising.
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/CustomTextProcessing/CustomTextProcessing.html#//apple_ref/doc/uid/TP40009542-CH4-SW8
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UITextInput_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UITextInput
Because iOS doesn't support system-wide keyboard customization, everybody just use system-default input facility. And handling of Hangul composition is all different by every operating-systems or platforms. (MS/Apple/Samsung/LG or others) So the best way is using system-supplied facility such as UITextField for consistency for users. Or you should accurately simulate how your platform OS does it. Of course you can make it yourself, but users won't like it.
Though I'm not expert on this topic - Korean Hangul compositor -, but I don't think there's simple algorithm without table lookup. Anyway if you really want to implement it yourself, these are all the core problems you have to handle.
Compositing your visual symbols into consonants and vowels which defined in Unicode.
Determining initial-consonant / final-consonants by placement of vowels.
It wouldn't be so hard, but anyway ability to modify preceding character sequence is required. You cannot implement Korean input with only one-way stream unless you have separate key for initial/final consonants which are looks same.
Unicode defines all valid set of Jamo components. Usually those components are too many to be presented on a device. And also inefficient. Most Korean input system decomposes those Jamo again and composite them once before compositing final litter. You also can identify and decompose them visually just like Korean people do.
After you get initial/final-consonants and vowels which are defined in Unicode standard, Unicode Normalization feature (such as -[NSString precomposedStringWithCompatibilityMapping]) will do the rest of jobs.
libhangul (code.google.com/p/libhangul ) does the conversion! It has several functions to handle different types of keyboards (i.e., keyboards with different layouts) and converting the keys to the Unicodes of Hanguls.
It also has several functions which combine the Hanguls to make syllables (they basically implement table lookups that Eonil has mentioned in his response).
Libhangul stores the Hanguls in its buffer as it receives them (it does not output them). After receiving enough Hanguls and successfully converting them into a syllable, it outputs the syllable. Unfortunately, this is quite confusing for the user. The way around this is displaying the buffer content on the screen. After receiving a new Hangul, what has been displayed must be erased. If a syllable has been successfully formed, then the syllable is displayed. Otherwise, the buffer content is displayed again. Note that you can’t just display the new Hangul on the screen. You must erase what you have displayed before and read the previous Hanguls and the new one from the buffer and display them on the screen again.
The reason is that Libhangul may change the code for the previous Hanguls stored in the buffer to make it possible to combine them with the new Hangul. This way, you will get the updated Hanguls.
Also note if the user changes the location of the cursor, the buffer must be emptied.
Additionally, if the user presses backspace, then, the last Hangul displayed on the screen must be erased and must be removed from the buffer.
Libhangul has also some features for correcting typos. For example, if you typeᅡ and ᄉ, it converts them into사.
Thank you JongAm Park and Eonil for your help and thoughtful comments! Since my reputation is less than 15 at this point, I can’t upvote your answers, but I will do when I can.

Unique computer ID like finger prints

Is there any unique computer ID that distinguishes a computer from other, like finger prints for human?
If yes, please advise how to get it in vb.net.
It is possible to put together info to uniquely identify a machine. This has already been done by many software vendors, most notably the Microsoft Activation service does it by sampling various bits of hardware on your system. The problem with this approach is that the identifier is not guaranteed to be persistent.
What i mean by this is:
the chances of another computer co-incidentally having the same identifiers is nil
if it becomes public knowledge which identifiers you are using it would be reasonably easy to spoof the identity of a machine
the identifiers can change over time as users change hardware, so the "fingerprint" will also change
For further reference, try these links:
Previous SO question: What's a good way to uniquely identify a computer?
MSDN forums: Uniquely identify computer
Just remember: the more points of reference you use to assemble your identifier, the greater the chance it may change at some point in time.
Try getting MAC + CPU ID + Motherboard serial. If you concatenate these then its you unique finger print of that machine until hardware changes occur.
Bear in mind, many people these days are working with dual operating systems (eg VirtualBox) and the MAC will be different. Even swapping network connectivity (ethernet hardwire vs wifi) will change the MAC. I would say MAC is not a good reference for identification.
Well it can be done in many ways.
You can try to get all kind of data about the computer, and then hash it to a string that will identify it. For example, number of drives, number of processors, the user's name, some keys in the registry.
But you have to make sure all the data you take is data that doesn't usually change.

embed serial number to PDF file?

To prevent the casual distribution of pdf document, is there any way such as embedding the serial number to the file?
My idea is to embed the id bound to user and enable to find who distribute the file.
I know it's not preventing the distribution but may discourage the casual distribution by the certain level.
Any other solution is also welcome.
Thanks!
Common way is placing of meta data, but you can easily remove them.
Let's search hideouts (most of them low-level)!
Non-mark text
Text under overlapping objects
Objects of older versions (doesn't noticed by reader, but there with redundant information)
Marks in streams between BX-EX (with weird information from readers point of view)
Information before %PDF-X
Information above %%EOF
Substitution of names for some elements (like font name)
Steganography
Manipulation from used fonts
Whitespacing
Images with setganograpy
My favorite are steganography and BX-EX block within stream, with proper compression and/or encryption it is hard to find (if do not know, where it is). To make search harder wrap some normal blocks with BX-EX.
Some of ways are easy to remove, some harder, but decided attacker will be able to find and sanitize them all. Think about copy-paste of text or print trough PDF-printer.
You can render transparent text. You can write text outside the media box of a page. You can add custom document property. There are plenty of ways to do this.
Why not create a digital id on the documents?

Selecting good, non-conflicting keybindings for a game

PC keyboards weren't designed for gaming, compromises were made to bring the price down, so some problems occur. Most importantly, when you hold down certain keycombos, some keys don't react to pressing.
My game has two users at the same PC control two characters in realtime (i.e. not turn based). An instance of the problem: player 1 holds Up and Left to go in that diagonal direction. Player 2 is then unable to go to the right (with "D"). Beyond being merely annoying, it can give an unfair advantage to a player who opts to use the bug as a cheat. Not fun :(
The basic commands are: shooting, walking left and right, and jumping. Shooting is done with LeftControl and RightControl, which don't conflict with anything, so let's consider only the movement keys.
On my laptop, most obvious keybinding combinations fail:
WAD and arrow keys fails with Up+Left+S and Up+Left+D
IJL and arrow keys fails with Down+Right+J (though Down is technically unused, a player often holds it down anyway)
arrow keys and numpad keys fail with Down+Left+NumpadLeft
all-letter combos like WAD and IJL tend to work, but I don't like leaving the arrowkeys unused, and crowding the users' hands together.
Is there a website that list statistics of common supported keycombos on various keyboards, to help me make my decision for defaults? (they're configurable, but defaults matter.) I seem to recall a relevant site called keyboardssuck.com, but I can't find it now.
How have you dealt with this problem? Just ignored it?
Does the problem depend on the OS, the API, the mobo? On anything else? I think it only depends on the keyboard model, but gotta ask.
edit: Now I know what this is called: "rollover"
The best bet is probably to let the user choose his own keybindings.
This is a hardware-implementation issue. To me this problem presented itself as depending on
how the keyboard is wired internally.
To me it seemed to be like theres no real standard to this. A certain combination of 4 keys
at the same time worked fine on one computer (a desktop-machine) - another keyboard simply
could recognize no more than 3 of those. (laptop)
My hunch is that you can rely on all of the control-keys (ctrl,alt,shift,windows,apple-keys) because they are probably wired on another "layer". But when it comes to "normal" keys including cursor keys, numpad keys and the likes, i would say that you can probably rely on 3 keys at the same time.