René Rebe

Intel released a new, tiny tool named “powertop” that can help to find possibilites to save more power on Linux systems. On the homepage they recommend:

Use a recent distribution
Linux is a fast moving project, with very fast evolving components. If you’re using an older distribution, older than 4 to 6 months (and anything with “Enterprise” in the name is by definition old), please consider going to a newer distribution. Reporting issues on older distributions is going to be frustrating to a lot of people, since the issue is likely to have been fixed more than 6 months ago… Please be considerate of the developers of projects and use a recent codebase and avoid bugging them about issues they solved long ago.

As I could not agree more, here we go: T2 SDE

… with powertop already included.

After answering where to get and how to build the k-drive, TinyX a few tines on the xorg mailing list I figured it is about the tine to let Google now about it more verbosely:

Keith Packard’s k-drive based, TinyX was merged into the mainline xorg-server package, so it is as easy as downloading the latest, greatest X.org release and configure the xorg-server package with something like:

--enable-kdrive --disable-dri --disable-xorg --disable-xorgcfg

along with the other options like –prefix et al. as appropriate.

If you want all this in an automated way, with cross compile support you can also take a look into the T2 SDE Project which among others supports exactly this: Cross compiling X.org, including the tinier k-drive variant, even with alternative C libraries such as uClibC and dietllibC. To check it out and give it a try the T2 Rescue target provides tiny ISO images, pre-built for at least x86 and x86-64 (other like powerpc and sparc are easily buildable from the T2 source as well).

… now running on Intel 686 CPU.

No joke - from the Gentoo weekly newsletter “16 April 2007″:

Gentoo Linux first distribution to run on Apple TV. … Our distribution was chosen due to the fact that it is one of the more portable Linux distributions and, as such, is often one of the first to be ported to new devices.

Now while it’s nice for all of us that the Mactel Linux folks got Linux booted on this “yet more closed and crippled” Apple device, I wonder what part of Gentoo should have played a role in that. After all those people just reverese-engineered and trial’n error enough to get a normal i386 linux kernel loaded. Nothing Gentoo would have helped in. So this statement boils down to:

Gentoo was “ported” to yet another i386 based device.

Congratulations.

And if you want to port - for example even cross compile - “with style”, a tip from my side: T2 SDE:

Running on i386 since its roots in 1998, Alpha, PowerPC, SPARC since 200x whatever, the first to run on AVR32, and running on any other 32bit and above silicon (ARM, Blackfin, MIPS, HPPA, SuperH to name some more), and comming with strong cross compile support out of the box. And best of all (aside that it’s free under the GPL as well): Gaining more out-of-the-box (Board Support Package) embedded vendor support every day.

Now that was something one should write more news about :-)

I was just about to add a link to the Gentoo ebuild of my MacOSD when I had to notice they just removed it!!! :-(

MacOSD is a tiny background UI daemon that displays brightness, volume change events among some others on Apple computers running Linux in two ways: an older XShape based textual way using libosd which works on even the oldest X-Servers and video overlays, and a newer, Enlightenment 17 Evas canvas based, view that looks way more pretty, but only works correctly on top of video overlays with latest X-Servers with enabled composite extension and a running composition manager.

Now it appears the Gentoo folks decided that Enligthenment 17 is too rapidly changing and introducing too much unstability and API/ABI breakage for their unstable, ever changing Gentoo distribution. They thus removed Enlightenment 17 and all packages depending on an E17 library - include the little MacOSD :-(. Even though MacOSD only does build with Evas support optionally, they still could have left it in the tree building with libosd just fine.

So for all begging for a more compelte and stable source distribution you might want to give our T2 SDE a try - of course MacOSD is included :-).

I have the Sony MZ-RH 1 for some weeks now (see the blog entry about it) and the Sony Windows software named SonicStage gets on my nerves so badly it is worth another blog entry.

The Hi-MD and especially the MZ-RH 1 are really fantastic devices but the usability of the Windows music (mis-)management software Sonic Stage just sucks. Sorry Sony but that’s how it is and you can easily find out googling for it …

The Pro/Contra list boils down to this Cons:

• Windows only (showstopper alone)
• slow
• looks ugly (heavily overthemed)
• does not read all CD (e.g. some with copy protection that otherwise read out fine with other software and sometimes even not ordinary ones without any copy protection at all)
• mutable locks all over the place, e.g. no name or meta info editing while importing a CD and the like
• crashes more often than not
• once corrupted the MiniDisc’s data integrity and as a result crashed even more often and forced me to reformat the disc loosing all my music on it!

You miss the Pros? Sorry that’s right - there are no Pros (despite if you like to count “after a lot of caffeine it sometimes transfers music files to the player - that is if it was able to read the CD and did not crash on the way).

Now not only does Sony force us to use Windows software where many people these days happily have no Windows anymore at all - this software is as annoying as I seldom have seen any other software in this millenium. Especially not in the content providing industry. Look at Apple’s iTunes or other HD Player that allow you to just drag’n drop your files on the USB storage device.

A pity this Software really prevents the Hi-MD from becoming a success, especially as Sony allows to drag’n drop mp3 onto and out of other models including cell phones (such as the k750i and m600i). On those cells you even can push the files too all the other people in school, a party or all the stranger in the subway just fine!

For the brave hearted I decided to publish my first bits to read the TOC and print the offset positions of the on-disc data structures rather now than later. Maybe someone else will take a look and help out decoding more of the disc’s meta data and the like. Much luck!

Historically the specification of tokens to be used in custom strings such as file names and report generation was just to use some special character such as ‘%’ or ‘@’ and pair it with some more ore less cryptic token to specify the kind of the replacement, e.g.: ‘%d.4′ or ‘%User’ and other variants such as ‘@day@’.

Of course this is not what today’s end users, especially on Apple Mac OS X want to see. I was already thinking how to make this more comfortable in one ouf our Mac products and with Adobe’s recent Lightroom demo I got an inspiration: Basically they use what Apple introduced with Apple Mail’s address field, rounded visual tokens you can inserted and drag around easily. So I set out to implement this using the NSTokenField, new in OS X 10.4, however I had to find out making it behave as wanted was not as easy as I hoped. One needs quite some Cocoa and ObjC experience to implement normal text intermixed with those rounded tokens and Google was quite sparse on on details and thus I decided to document the details here:

Note I’m not a Cocoa guru - feel free to comment suggestions and improvements!

Of course introducing it in your UI just means dropping it ouf of the Interface Builder’s toolbox into your project. The difficulties begin when you want to control the appearance of the tokens and display some as ordinary text.

For this you need to create your own class and add it to the NSArray that the NSTokenFieldCell uses to hold the tokens. Furthermore you need to define a delegate for the NSTokenField so that this delegate can respond to requests such as:

- (NSString *)tokenField:(NSTokenField *)tokenField displayStringForRepresentedObject:(id)representedObject

and

- (NSTokenStyle)tokenField:(NSTokenField *)tokenField styleForRepresentedObject:(id)representedObject

so you gain control about the formating of the individual tokens and the ordinary text parts can get the default NSPlainTextTokenStyle and you can return NSRoundedTokenStyle as well as the display text for your custom tokens.

When you want a context menu for your tokens you furthermore need to implement:

- (BOOL)tokenField:(NSTokenField *)tokenField hasMenuForRepresentedObject:(id)representedObject

as well as:

- (NSMenu *)tokenField:(NSTokenField *)tokenField menuForRepresentedObject:(id)representedObject

and to allow drag’n drop of your precious tokens your class need to adhere to the NSCoding protocol and implement:

- (void)encodeWithCoder:(NSCoder *)encoder

and

- (id)initWithCoder:(NSCoder *)decoder

and though deprecated you must use the old, non-keyed coding and decoding for this drag’n drop code:

In my example code this just was:

[encoder encodeObject:name];

respective:

name = [[decoder decodeObject] retain];

I hope this is a help for other people that want to use the NSTokenField and find the current Apple documentation slightly lacking detail. The full Xcode project is attached below:

TokenFieldTest

Recently I sumbled over Adobe Lightroom - a still beta digital RAW image post-production suite. It’s GUI is truely remarkable - featuring the same “game based” interface design rules we wanted to implement for our audio software since some years now.

Even more remarkable is that about 40% of the code is written in LUA - respect! You can see a note about this in the copyright / acknowledge dialog and a there is a matching presentation from an Adobe employee about Experiences building a desktop application with Lua presented at a LUA workshop.