Oct 26, 2007

WIndows XP on OLPC??

Picked up over at Reddit, MSFT is really trying to compete with OLPC:
Microsoft Corp (MSFT.O) has made progress in getting its Windows software to work on a low-cost laptop computer for poor children that currently runs on rival Linux software, an executive said on Thursday.

And I find it preposterous. And they're getting it wrong, again. Redmond does not seem to understand, that this is about children and education, not about how to milk everyone of the last penny.

The sole purpose of a $100 laptop project (now One Laptop Per Child) is to bring education and to empower children. To help them learn things and do that in the most adventerous way. With all due respect, Redmond cannot produce any of that, because they can't see a classroom behind their greed.

Wake up, Bill, Steve. This is not what you think its about, although you are right — this can well make you history.

Oct 19, 2007

C-fonts from Microsoft

There's an article over at Slashdot referencing a blog post at hunlock about new Microsoft "core" fonts. The post is a bit dated, from April this year, but /. has just picked it up.

I saw a link to hunlock back in April, most certainly over at Reddit. I have tried and installed the C-fonts on both a Windows PC and a Mac. The process did require a download of PowerPoint 2007 viewer, as there's no other legal way to download these fonts.

I found Cpnsolas to be a nice replacement for Andale Mono and Courrier New (but not the original Courrier). The rest of the fonts I played around with and concluded that I seem to *not* like most of them.

For one, Microsoft seems to prefer small sizes, regardless of what usability experts say. These fonts are tiny, at 12pt they feel just about as big as "old" core fonts at 10. I also find them to be too thin -- which maybe a reflection of the battle of "readability vs. correctness" debacle between Apple and Microsft on font rendering.

Oct 17, 2007

The 300+ changes in Leopard

I have been going through the Apple‘s 300+ New Features page and quite a few made me feel excited and much more eagerly waiting for Leopard than before. Here‘s a quick run-down of what I like on that list:

AppleScript: Full Unicode Support for AppleScript.
Finally. With the rest of Mac OS being so much pro-Unicode, Applescript‘s (and its editor‘s) disabilities in that area, the need to hack a Unicode string to be processed and/or displayed correctly... The only thing better than that in AS would be better/stronger dictionaries into iTunes and iWork apps!
Automator: UI Recording and Playback
This is what should theoretically be possible in AppleScript (but I have never ever been able to record anything), would be a great pluas for Automator, maybe it would finally help it to become a much more useful tool.
Dictionary: Wikipedia in Dictionary
Very handy, I suppose.
DVD Player: Chapter Thumbnails
Nice addition, as I‘ve been more frequently using VLC lately, due to it‘s ability to skip all the legal crap front matter. This is not the same – but at least a nice addition.
Finder: Back to My Mac
I still need to see exactly how this will work. And a bit concerned of (potential) security issues around this.
Imaging: Network Scanning Support
I‘ve got this HP PSC (printer/scanner/copier) device that is hooked to AirPort Express for printing. But I can't use it as a scanner this way. I wonder it this feature would allow me to?
International: Russian Localization
I wonder if that, coupled with "New Fonts" feature will finally give me a few more fonts to choose from and a bit better appearance of Cyrillic pages in Safari? Or does this only cover translations of interface elements?
Mail: To Do and Notes
Very nice productivity enhancement.
Safari: Movable Tabs and Merge All Windows
Ok, for these I don‘t have to wait till Leopard – I can have them no in Safari 3.0 and these are cool and useful. The former I can do in FireFox, but the latter is, actually, much more useful.
Security
A whole host of features there that look quite promising.
Terminal: Improved International Support, Tabs, Workspaces
Borrowing from iTerm and screen(1) :)

Oct 1, 2007

Which Emacs.app?

There're many versions of GNU Emacs to choose from when it comes to MacOS. There's a standard console-only Emacs that comes with the system. There's Carbon Emacs that (as the name implies) uses Carbon libs. There's an Aquamacs — again, the name is telling. But what I found to be a very nice addition to this group is Emacs.app — a Cocoa-based Emacs version.

It is still in development and shows a few rough edges here and there — but I find it a lot more responsive (and a lot less pretentious) than Aquamacs, while being a proper Cocoa application (as much as it can be said about Emacs). Moreover, its code base is a lot more current than either of the alternatives, hence you get a few added whistles, like code checking in most popular languages (e.g. Perl).

To be fair — there more Emacsen to choose from, see this page on EmacsWiki.

XML::Simple oversimplification

Perl's XML::Simple module is an easy way to get your application to talk some basic XML. it uses expat to parse data, so there the leverage is good. But where things tend to go awry is with consistency of reading and writing back.

Example

Let us take the following sample XML document:

<data>
  <survey key="123">
    <description>A survey with a description.</description>
    <qa key="1" type="radio" text="Only one valid option in answers">
      <a key="1">Enie</a>
      <a key="2">Menie</a>
      <a key="3">Be</a>
    </qa>
    <qa key="2" type="text" limit="255" text="A long comment field, with a set length limit (default to 500 characters)">
      <a />
    </qa>
  </survey>
</data>

Once read in and dumped through Data::Dumper, it is represented thusly (keeproot option of XML::Simple was set to 0):

$VAR1 = {
  'survey' => {
      'qa' => {
          '1' => {
                   'a' => {
                            '1' => {
                                     'content' => 'Enie'
                                   },
                            '3' => {
                                     'content' => 'Be'
                                   },
                            '2' => {
                                     'content' => 'Menie'
                                   }
                          },
                   'text' => 'Only one valid option in answers:',
                   'type' => 'radio'
                 },
          '2' => {
                   'a' => {},
                   'text' => 'A long comment field, with a set length limit (default to 500 characters)',
                   'type' => 'text',
                   'limit' => '255'
                 }
        },
      'description' => 'Second survey with a much longer description.',
      'key' => '123'
    }
  };

However, writing out with XMLout does not produce XML file one has just read in:

<opt>
  <survey key="123" description="Second survey with a much longer description.">
    <qa name="1" text="Only one valid option in answers:" type="radio">
      <a name="1">Enie</a>
      <a name="2">Menie</a>
      <a name="3">Be</a>
    </qa>
    <qa name="2" limit="255" text="A long comment field, with a set length limit (default to 500 characters)" type="text">
      <a></a>
    </qa>
  </survey>
</opt>

XML::Simple is unable to distinguish from the nested Perl hash whether an item is an element attribute or a tag — see how <description> has become an attribute? Forcing array out put helps, but causes, for instance, the same <description> tag content to be wrapped into a single element array.

Perl code to do reading and writing of the above:

#!/usr/bin/perl -w
use XML::Simple;
use Data::Dumper;
$xmlDoc =<
<data>
  <survey key="123">
    <description>A survey with a description.</description>
    <qa key="1" type="radio" text="Only one valid option in answers">
      <a key="1">Enie</a>
      <a key="2">Menie</a>
      <a key="3">Be</a>
    </qa>
    <qa key="2" type="text" limit="255" text="A long comment field, with a set length limit (default to 500 characters)">
      <a />
    </qa>
  </survey>
</data>
END
$xs = new XML::Simple (forcearray => 0,
                       keeproot => 0);
$xRef = $xs->XMLin($xmlDoc);
print Dumper($xRef);
print XMLout($xRef);