by Michael S. Kaplan, published on 2005/09/15 10:01 -07:00, original URI: http://blogs.msdn.com/michkap/archive/2005/09/15/467594.aspx
Christoph Päper posted the following to the Suggestion Box (my comments interspersed, which include some thoughts on why things are as they are today, which is not to say they may not be different in the future!):
I know, MSKLC, which is a program I had long been waiting for, is an unsupported piece of software, but maybe you are interested in my remarks anyhow.
Always! Feedback is always appreciated.
For what it is worth, large parts of the functionality of MSKLC is a wrapper around the core functionality in Windows related to keyboarding and thus there is very little about what it does that can be called unsupported....
IMHO MSKLC needs improvement in one crucial area: documentation of the generated keyboard layouts.
The first issue is that it only generates JPEGs instead of artefact-less PNGs or GIFs (eight colours are enough anyway). For some users they also do not look similar enough to a real keyboard. It would also be nice if KLC could make pictures of all shift states at once, or even combine them in a MNG or animated GIF. OTOH you may not want pictures at all, but for example an HTML table resembling the keyboard—I always wanted to write a .klc parser for this task myself, but somehow haven’t gotten far with that yet. In both cases, bitmap and HTML, I’d like a combined view where each key has four cells: normal in the lower left, shifted in the upper left, AltGr in the lower right and shifted AltGr in the upper right; with different colours for dead keys. Yes, that leaves out SGCaps, but is the style current (hardware) keyboards are using, at least in ‘Latin Europe’. You would probably also need a feature to get an overview of dead key combinations, but I’m not sure how that should look like.
More sophisticated methods of documentation are definitely a possible item to consider for the future, but I am not sure it would necessarily take the route you suggest here -- considering each key can take up to four WCHARs per shift state, a keyboard that can fit sixteen characters and sufficient space between them is a tall order, and the dead key situation is also not a trivial one.
Dynamic HTML like that used by the Windows Keyboard Layouts site is a possibility, but the magic behind such sites is a huge image cache of letters, which would presumably have to ship with the keyboard?
One of the things that kept there from being a more comprehensive story around documentation is the fact that there are no easy answers, and there were many people who were wanting the solution to be available without delay. There are compelling features being considered for the next version and I won't claim that this is not one of those features under consideration, but there is some stiff competition!
Furthermore I miss the possibility to assign the actual glyphs that are printed on the ‘÷’, ‘×’ (or ‘·’) and ‘−’ keys to their shift or AltGr states; likewise ‘A’–‘F’ to ‘0’–‘5’. (Nobody seems to want to produce keyboards with hexadecimal numpads.) Only ‘.’ on ‘,’ works right now.
Definitely worthy of consideration. This sort of limitation is probably more of a side effect of the mission of the tool being priomarily focused on language support and the ability to design keyboards for languages we have not yet gotten to -- thus "getting out of the way". The other factor that makes it a tough feature to work on is the amount of screen real estate that it would take up, and the resolution that would be required to support such a keyboard....
Why can’t I click on the symbolic Shift, Caps/Shift Lock, Ctrl, Alt and AltGr keys to see that state? They don’t even change colours when they’re the active view. I can understand that hitting them on the real keyboard doesn’t work, because they might be needed for accelerators etc.
It is something of a self-referential tool -- a keyboard layout creator that looks something like a keyboard. We actually tried many different designs, including ones along the lines you are suggesting here and ones that would allow a layout to be tested directly as if it were a soft keyboard, and many of these attempts produced a tool that was simply too difficult to use. I will forward the suggestions on though (as well as your other suggestions) as they may spark other ideas that could overcome those issues.
Unlike some other customisations (‘skins’ etc.) there seems to be no ‘central’ place to promote and distribute one’s keyboard layouts on the Web. If we wanted to change default keyboard layouts to something better such a place would be much needed, IMHO, and it should provide the aforementioned documentation for each .klc. Therefore it’s better if it’s compiled uniformly by KLC itself and not by some homebrew or third-party program.
The community aspect of this suggestion does indeed have a lot of appeal. There are of course many complex technical and legal issues to work through before such a thing could happen, but it is a worthy goal and the potential of such a site is fascinating to contemplate. Another great idea....
Finally, what does anyone need Caps Lock for nowadays? Text in uppercase or small-caps is (or should be) handled on an application or font level.
I am not sure what this last part is to do with MSKLC though -- changing the fundamental nature of applications to require them to handle the CAPS LOCK is not something that MSKLC can drive, or even ponder -- and also there are many times that CAPS LOCK is not used for case distinctions (plus there are things like SGCAPS that are an even more complex usage). I do not know of any case where the need for different shift states to hold case distinctions is not a fundamental requirement of a keybioard for scripts that have such distinctions, or how MSKLC (a mere wrapper around the functionality in Windows) could change that architecture.
But there are some great suggestions in this post, definitely worthy of consideration. Thank you very much for the feedback!
# Jonas Grumby on Thursday, September 15, 2005 2:48 PM:
# Michael S. Kaplan on Thursday, September 15, 2005 2:53 PM:
# Shai on Tuesday, September 20, 2005 2:05 PM:
# Michael S. Kaplan on Tuesday, September 20, 2005 2:23 PM:
# Shai on Tuesday, September 20, 2005 3:53 PM:
# Michael S. Kaplan on Tuesday, September 20, 2005 4:15 PM:
# Michael S. Kaplan on Tuesday, September 20, 2005 4:44 PM:
# Shai on Tuesday, September 20, 2005 5:03 PM:
# Michael S. Kaplan on Tuesday, September 20, 2005 5:07 PM:
# Shai on Tuesday, September 20, 2005 8:29 PM:
# Michael S. Kaplan on Wednesday, September 21, 2005 12:26 AM:
# Philip Thomas on Sunday, September 25, 2005 5:49 PM:
# Michael S. Kaplan on Sunday, September 25, 2005 8:13 PM:
# victor on Tuesday, October 04, 2005 1:33 AM:
# Michael S. Kaplan on Tuesday, October 04, 2005 1:44 AM:
# Philip Thomas on Wednesday, October 05, 2005 3:27 PM:
# Michael S. Kaplan on Wednesday, October 05, 2005 3:44 PM:
go to newer or older post, or back to index or month or day