Chrome has an ugly habit of storing saved passwords in KWallet as pickles, which you can't just read from KWalletManager when you need to get the password. This is problematic if you want to switch browsers, or just use more that one but don't want to launch and delve into chrome just to get that one password.
Although the pickle format doesn't seem standard, it mostly works to get every other character as to excise the utf16 (or whatever) text and eyeball the password. Here:
Remember how I used to hack Sony Network Walkman NW-E507? Well, back then, I succeeded and it did work, but soon after that the device got stolen so I never polished it up to release quality. But even though it isn't release quality and I'm not even sure the code I got is the working one (although commit history does suggest so), I decided to publish it anyway. Perhaps it will be useful to someone.
Android Developers Blog: Integrating Application with Intents — a nice writeup about really, seriously underappreciated Android feature, Intents. Somehow it's reminiscient of the revolutionary Magic Ink proposal, albeit on a push, not pull basis.
Having said that, I can't shake the feeling that making up URI schemes is not cool. Especially when they're made up to go with an Intent action which is actually redundant with the scheme. URI should point to a location, not embody action; actions should go in the action field (hey, action–action, ya see? almost like it was designed for that!).
Kernel 2.6.28 adds brand new WiFi regulatory domain handling; so if you upgrade from OpenSuSE 11.1 to 11.2 (and so from 2.6.27 to 2.6.31) you get this shiny new (FCC) sheriff's badge right there too. This is all fine and cool, only the userspace part is utterly broken in SuSE, so you're limited to world regulatory domain.
Ah, well, downloading Lineville's regulatory.bin fixes it. (Only it's a bit hard if you have NO FREAKING NETWORK because you use channel 13 on your AP and your OS decides that it's no channel 13 for you.) Or does it? Wait, it only gets better.
Now, apparently, your network card feels a citizen of the world. It doesn't matter you're an EU citizen in the EU and that the computer has been bought in the EU. EEPROM says world regdom, the kernel must obey. So you end up patching the driver to report correct regdom to kernel (because it obviously won't just let you override it, you malicious, evil bastard, you). I sure hope you have that kernel source around! And development tools. And stuff. Although I'd advise against those -s in the patch, they seem to break it further, dunno why.
Apparently you can use ath_info to patch up your EEPROM to report correct regdom, so you don't have to patch up ath.ko every time a kernel upgrade comes down the line. Fortunately the 11.1 repo's version still works. (It's regdom 0x37 for EU.) Just that... the card refuses to write it. So you're stuck with patching. Or just shut up and don't use channel 13. Which might explain exactly why it's usually less crowded. (Which, incidentally, is exactly why you'd want to use it.)
Oh, wait, you can enable EEPROM writing on AR5110. You just need to pull the GPIO EEPROM write enable pin. Of course, there's no datasheet anywhere in sight. You're lucky your humble editor took the risk and brute-forced all 10 pins (ok, not all, but he was ready to) and found the magic combination. It's # ath_info -g 1:0 -w <base-address> regdomain 0x37. lspci -v will tell you the address.
If you have a Radeon with analog LCD panel and after upgrading something (possibly the radeon driver) SPAA suddenly no longer works for you in Qt4, try the following:
$ echo Xft.rgba: rgb >> ~/.Xresources
$ xrdb -merge ~/.Xresources
I'm too pissed off by this and debugging it for two days to offer any explanation (just to note, radeon's Option "SubPixelOrder" doesn't work; if you feel like digging, see qfontengine_ft.cpp, libXrender's and libXrandr's source). Also, YMMV. If it works you're on your own to make sure it gets loaded properly.
Interactive fiction interpreter for Android released! Look at the code or just grab the package at Market.
Android documentation says:
public int ledARGBThe color of the led. The hardware will do its best approximation.
Best approximation my ass. I wanted #fb2a0c, I got pink. To get the orange color, I needed #080800, for which orange is most certainly not what I'd call best approximation. It seems that Dreams' drivers just feed the raw RGB values to the hardware without bothering to do any processing on them.
To make it easier to find out which color to feed your device to get the real best approximation of color you want, I made this quick and dirty android LED tester. Just slide the sliders until you're satisfied, note the values and get on with it.
As a note, you might want to only serve the fake colors to devices you tested them on, in case other devices handle this properly and your app would turn out to blink the LED in real #080800, which is to say, almost black. I do this with if (Build.DEVICE.equals("dream")) color = 0xff080800; else color = 0xfffb2a0c; obviously if you test on more devices and they're all equally quirky, you need to add more checks.
