Making use of caps lock. ... No, seriously.

It is true. No longer will caps lock be the key that you accidentally hit an then hate for what it's doing.

So what is this about? A while ago I read about that fantastic idea of making the caps lock key behave like escape on Wolfgang's blog. Which is really an awesome thing, especially for vim users.
But we don't want to eliminate caps lock. We want to make use of it. So: I recently switched from a German keyboard layout to a standard US one. Quite soon I realized, that I woudn't mind writing umlauts (äöü) as ae, oe, ue but I'd really miss the s z ligature ‌ß
It then occured to me (i.e. after wining about it on irc someone reminded me) that I could use compose. Which I, till then, only used for my beloved dash (—).

But something was bothering me: while the origins of the ß are a bit complicated (the story includes the long s (ſ), a character that isn't used anymore, and there were different versions of the ligature using either the z or the s) and German speaking countries that don't use the ß, like Swizerlad, use ss instead, it's present name Eszett (naming the letters s and z) and things like the HTML entity being ß (s z ligature) make the ß — for me at least — more a ligature of s and z than of s and s. Yet, the default compose sequence for ß is ss. I had to change that.

While creating my own .XCompose file I had the idea to create compose sequences for hiragana (the reason why that's useful to me is a whole other story). But what would I use? <Multi_key> <a> for あ, <Multi_key> <n> <o> for の, etc.? Would be quite annoying to be forced to hit the compose key (mapped to the menu key in my case) for each and every hiragana. There had to be a better solution.
I looked into different input methods for Japanese, but aside from the fact, that they'd clearly be more sophisticated than what I'd come up with (due to me only having really basic knowledge of Japanese), they weren't really what I wanted to have.
I then thought about a separate .XCompose file for hiragana that simply woud map a to あ, n followed by o to の etc. and which I could load using some key combination. Turns out you can't change your .XCompose file on the fly. You have to restart X. :/ (At least I found no way to do it.)

After a while of thinking and testing I had the idea to use a modifier for my hiragana compose sequences. More specifically: a modifier that can be toggled on and of: CAPSLOCK!
What this means is, that for example a gets "composed" to あ, but only when the modifier is active. The cool thing about that is, that you even have an LED indicator for which "input mode" your in. LED off = romaji, LED on = hiragana. This of course can be used for anything. Instead of a hiragana mode you could have a writing upside down mode, a Greek mode, etc.

If you want to try it out, here's my current .Xmodmap (swaps escape and caps lock and set's compose to the menu key) and here's my .XCompose file.

2012-09-16

Raspberry Pi + Lego Case :3

Maybe not that interesting, but I felt like this had to appear here. I got my RPi in July and recently started to build a Lego case for it. The one you see on the picture (fullsize) was initially just "find as much red parts as possible and use the other colors to create a prototype".
After a while I started to replace strange colors (brown, green, pink, etc.) and black as well as grey bricks in my prototype with similar parts in blue, white or yellow. What you see is how far I got ... a few flat parts and a bigger "window" for the LEDs are still to be found. The completely red version is far from complete. I'd need 9 1x1 flat bricks with a flat surface on the top — not sure if we have that much.

Anyway — the Pi is up and running, serving mostly as an IRC client at the moment; guess it'll have the honor to take care of one or the orther cronjob in the near future and offer some web based "services" for me.

Miscellaneous information: I got the idea to build a Lego case from Biz's LEGO case. I used pants for my case because they leave a bit more space inside. Everything located above a slot is fixed to the lid, so the Pi can be taken out once the case is opened withough the need to take it apart. I noticed that my case might not leave enough space for an RCA plug but I don't plan to use it anyway. I use Arch Linux ARM. Here's a picture of my Raspberry Pi next to a raspberry pie.

2012-08-14

JSONProxy

Before I begin with what this is actually about, some words for those who aren't familiar with AniDB, MyAnimelist, XDCC-Bots or at least one of those:
AniDB and MyAnimelist are both websites that let you create a list of anime titles. In the case of AniDB the focus lies on the anime episodes you have stored somewhere, MyAnimelist cares more about what episodes you saw.
XDCC bots are IRC bots that send you files on demand. They are a common distribution method for fansubbed anime and offer so called packlists, where the list all the files they offer.

Now to the real story: I'm a user of both AniDB and MyAnimelist, but I only maintain a list on the latter. I use AniDB of keeping up to date with newly released episodes of airing series. The problem is, that if you only want to see notifies for new releases of certain subgroups, you have to add episodes of the respective anime from that subgroup to your list. I, however, don't maintain a list on that site, so I'd get a ton of unnecessary notifies.

Now, since I get all my new episodes from XDCC bots I though I could make use of simply parsing their packlists, which was the first thing I did: write a JSON file with all neccessary info, a small PHP script to parse the packlist and a minimalistic site to display the output. With that I always had an up to date list of all released episodes of the series I watch and only from the subgroup I want them from.
The problem with that approach was, that I had to memorize the number of the last episode I saw for every of those anime. So I had to come up with something different. Since MyAnimelist always has the information on which episode of which anime I watched last it seemed natural to use that. Also, since I open the page with my list on it several times a day, it seemed to be a good idea to simply include the information about new episodes there.

So I wanted to write a userscript that should obtain the information from both my JSON file and the packlists, look at the site itself and, if there were any episodes released that I hadn't seen, inform me about that ... well, same origin policy says no. The userscript is written in JavaScript and common browsers won't let it perform an XMLHttpRequest for stuff stored on other servers than the one the site you are viewing when the script is executed is hosted on.
I had to find a workaround and I though of JSONP, a method where you create a new script tag in the head of the site with the remote thing you want to access as the src attribute of that tag. Problem is, that remote thing should be a string with a JavaScript method call, so that you actually can use what you got from the remote server. But I wanted to access packlists I had no control over. It then came to my mind, that I simply could write a PHP script that would access and parse the packlist and return a JSONP string — a JSONP proxy you could say. ^^ And then access this with my userscript.

This is what I ended up doning. :) My JSONProxy parses packlists based on my listing of urls, titles and subgroups and my userscript (actual code) uses that to inform me about new episodes. :3

I guess it would be quite easy to write a universal JSONProxy which takes a get parameter (the url to the document one wants to access) and returns a JavaScript method call with the whole site as a parameter. What I'm not sure about is, wether or not there are regulations on the src attribute of script tags and how messy the escaping of whole websites for the JS method call would get. ^^
Oh and by the way: since the actual request to the site you do not control (in my case the packlists) is not performed by the browser the JS is running on but by the PHP script on your server this method doesn't even violate the same origin policy more than JSONP itself — it's just a handy way to access data from other servers when you write userscripts. :)

2012-07-19