by Michael S. Kaplan, published on 2012/04/12 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/04/12/10292952.aspx
Previous blogs from this series:
I've talked about Digit Substitution a lot over the years.
I pointed most of those blogs in, ironically enough, the blog that pointed out probably the biggest thing ever done at Microsoft to move away from Digit Substitution, Suddenly, in a bit more time than a blink of an eye, 'standards support' becomes 'less i18n support'.
I mean, every technology kind of chipped away at that support a bit more at a time.
Most of the blogs I point to are about the limitations and bugs and problems and inconveniences of the feature.
The underlying frustration about everything wrong with the faeture was hard to ignore....
But now that may all be changing a bit.
Starting not long after the internal meeting talking about the problems raised by the IE decision to move away from Digit Substitution, one of the developers working in the Windows 8 "Modern" space took note of how this difference could affect some people building Modern apps that are browser-based.
And a plan formed to make sure that developers building Modern apps would have a way to get some flavor of the Digit Substitution feature.
Obviously, there was no way to change every keyboard.
Or to change the logic of parsing and formatting in all of the other places that has been doing this work for so long -- as broken as they may be.
And now this support can be in the Modern parsing and formatting support, via all of the following:
Now these doc topics as they stand have are a little broken -- since these properties return the name of the script of the digits, e.g. Arab or Latn or whatever script tag you like, rather than the actual digits like NLS does.
But that bug will I'm sure be fixed soon, so who cares? :-)
The cool part about all this is that this capability to get actual naive digits, or to parse them, in a way that fixes almost every problem or limitation I've written about in this Blog since late 2004 and in online forums before that.
I am staggered by simple it ended up being to ignore all of those limitations and bugs and problems and inconveniences. And just do the feature correctly in the middle of the globalization library while ignoring the problems posed by keyboards and NLS functions and such.
In so many ways, this is the support that .NET should have done back in 2001!
I'll be talking about this more some time soon, I just wanted to make a moment to tip a hat to the Modern version of Digit Substitution, which gives me so much less to complain about that it makes me want to write Modern apps (even before I get to lots of other features I'll also be covering that take many of the same approaches to unchaining us from old bugs while re-imaging new features!).
Of the 22 parts in this series, this is one of my favorites -- because it's not just a game changer. Because it changes a game we've been playing against ourselves and losing for more years than I've been in Redmond....
Claudia Lawrence on 12 Apr 2012 7:34 AM:
the less and less i understand your posts, the more and more i read them.
asdf on 12 Apr 2012 11:25 AM:
I'm not a big fan of the term Modern apps. Metro is for silly toy apps with pointless restrictions, I'd rather move to Linux than Metro. (WinApi 4eva)
asdf on 12 Apr 2012 2:01 PM:
Yay censorship?
Simon Buchan on 13 Apr 2012 4:09 AM:
@asdf: Lol.
"Modern" may be a dumb name, but "Metro" is the name of a design style - we don't call apps for OS X "Aqua" apps, do we? Whatever we end up calling them, though, one thing is clear: The WinRT APIs are so much more clearly designed and simple to use, and often (as in this case) far more functional than their WinApi equivalents. @asdf may currently have a point in that they do suffer from some "pointless restrictions", but I expect as the API matures we will finally end up with what everyone's been asking for essentially the last 20 years: throwing away the old API (except for compatibility, of course!) and making a new, clean one from scratch. Not that is much comfort for all the people suffering with me with it's lack of support for multiple monitors right now....
Michael S. Kaplan on 13 Apr 2012 7:24 AM:
Good point, @Simon -- this case kind of proves it! :-)
asdf on 13 Apr 2012 12:01 PM:
I use windowS, not one or two tiles. It might be fine on a tablet but I'm talking about desktop usage here. While I agree that WinRT will probably be a better designed api, the fact that it is so locked-down means that I don't feel like supporting it. (Which is why my only choice when getting a phone was Android)
The fact that you are not allowed to do IPC with TCP on localhost in WinRT is silly. (Until someone creates a 3rd party server where apps can connect and talk together)
Also, if you read the Certification requirements ( msdn.microsoft.com/.../51A7C609-94AB-49ab-B8E0-F26FF776DDB4.aspx ) you see that you will not be able to create a GTA style game. And from the App Developer Agreement ( msdn.microsoft.com/.../hh694058.aspx ): "Microsoft may remove or suspend the availability of any app from the Windows Store for any reason or no reason" (The no reason part smells like Apple) and "...or to comply with _any_ judicial process, government order or lawsuit settlement." (Does this mean US or any country?)
As a power user and developer I just don't see how I can _work_ with that interface. Add to that the technical restrictions/lock-down, restrictive store policies (Bypassing the store is not an option either) and political/legal restrictions and my willingness to support this direction MS is going in is NULL. I have been a MS supporter since DOS but this time I have to take my ball and go home (In the name of freedom)
@Simon: If you look on MSDN you see this for some functions: "Applies to: desktop apps | Metro style apps" (FreeLibrary in this case) clearly we are not talking about design styles here.
Love your blog Michael, sorry I had to puke this all over it...
Simon Buchan on 13 Apr 2012 7:03 PM:
@asdf: I won't try to change your mind about this (heck, I probably won't be checking back), but so you understand where I'm at on this, I agree with you on the current restrictions, but as I see it they currently exist only to reduce scope on ensuring security of Windows Store apps - things like IPC don't make as much sense in the way those apps are currently made (regardless of platform). Otherwise Microsoft would be crazy - dropping their "Developers, Developers, Developers!" mantra when Apple is gaining a lot of traction in the developer market seems incredibly self-defeating. I doubt I'll know for sure until Windows 9 or even 10 though, so for now I'll assume they're *not* crazy.
Oh and they're named *after* the design style, that's why it's "Metro style application" not just "Metro application": it was developed originally for Windows Phone 7 I believe, but it's been taken by everyone from MSDN to XBox. Calling WinRT apps "Metro" when they're (for example) a FPS with flashy 3D holographic HUD and no flat-color tiles or text in sight is just silly. I'd prefer something like a "Tile" (from how they're started) or "Pane" (from how they're managed) app, to contrast the "Desktop" naming.
referenced by
2012/10/26 The evolving Story of Locale Support, part 28: We finally fixed that 'Install New Languages' thing!
2012/10/02 The evolving Story of Locale Support, part 27: No, the T and the H aren't silent...
2012/08/20 The evolving Story of Locale Support, part 26: Hey Windows 8, there's someone on the phone for you.
2012/06/07 The evolving Story of Locale Support, part 24: I Adar you! Hell, I Double Adar you! (Windows 8 ed.)
2012/06/05 The evolving Story of Locale Support, part 23: Tamazight? Outta sight!
2012/05/04 You know, it isn't always about us...
2012/04/16 ١, ٢, ٣ o'clock, ٤ o'clock digit substitution...