Braindead X11 Clipboard Exposed

I've been using Linux with X11 as GUI system as my primary and only work system for like 6 years now. It's great, much better than another world - asymptotically.  But there're few issues which sustain - an  being hated - for years. One of them is how clipboard in X11 works. It works illogically, unpredictably, and non-reliably. Based on many years' background black-box analysis, there appears to be more than one clipboard buffer, and some apps apparently take clipboard with themselves when they quit.

It finally came a right moment to both be hit by it and have time to investigate. This blog post shares the same sentiment as I above, and confirms suspected design braindeadness.

To quote:

Three selections are defined in the ICCCM: CLIPBOARD, PRIMARY, and SECONDARY, each of which behaves like a clipboard in its own right:

• CLIPBOARD: traditionally used when text is copied and pasted from the edit menu, or via the Ctrl+C and Ctrl+V shortcuts in applications that support them.
• PRIMARY: traditionally used when a mouse selection is made, and pasted with middle-click or Shift-Insert.
• SECONDARY: ill-defined secondary selection. Most applications don't use it.

Be gone soon, X11, be replaced by something sane.

NSLU Optware for Android

Yes, there was kind of attempt at that already, but:

• It's no longer available at the link announced and spread over the Internet (yep, it's available at another, but why so ... complicated?)
• It ships binary blobs of unknown origin. Yup, maybe one could trace their origins, but who'd bother, and telepaths are on vacation as usual. It should be described stringently where they are from, if not scripted to be collected in user's build directory from known good sources, so users can actually trust them.
• It is marketed as supporting only something called "Nook Color". What's that, I thought it was Optware for Android? Could I have Optware specifically for my HP nx9420 notebook, serial number XYZZY, 3Gb of RAM? Just make sure it's different from the Optware for the same notebook, but with 4Gb of RAM, and from any other Optwares in the world!
• It goes as far as patching rootfs ramdisk. That may work on Nook Color or may brick it. That may work on next firmware upgrade of Nook Color or may brick. That may work on another device or may brick. The talk is not about this, it's about the fact that it's two big differences - to be able to install and run bash and to have sshd started automatically after the boot. I definitely want first, but I will do good consideration if/when I need second. So, I don't want setup for those 2 stages to mixed and done without myself being ready for stage 2.
• It still appears to rely on presence of some other 3rd party stuff (look at that #!/bin/sh line, there's no such thing on pristine Android device, only #!/system/bin/sh)

So well, I decided to take my turn on hacking up an Optware bootstrap script for pure Android (root and adb access are the only prereqs). It's hosted here: https://github.com/pfalcon/optware-android and intended to be run on a Linux hosts. It starts by downloading CodeSourcery toolchain for libc and ipkg and immediate dependencies from http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/stable to bootstrap ipkg on device. Yep, it's being tested on Nook Tablet so far, but at least it is called Optware for Android and I have that aim ;-). So, bugreports and patches are welcome. And I have few more devices to test it on, just steal me some time...

Towards decent mouse wheel support in Android

One thing everyone would notice on attaching a USB mouse to an Android device is that mouse wheel is not supported, which makes interaction very tedious. I take a quick look at the state of its support.

Android-x86 project advertises mouse wheel support, but looking at their patch, they translate mouse wheel clicks into up/down buttons. That's better than not supporting wheel at all of course, but still not intuitive usage. What I'd like to have is not analog of up/down key press, but actual scroll, i.e. analog of drag.

But probably, such behavior couldn't be reliably emulated on the lower level of input processing, (or this might lead to adverse effects, like mouse wheel movement interpreted as click). Instead, higher-level controls should have explicit support for discrete scroll events. For example this event handler block should be factored out to be callable for such event and be passed just deltaY.

Of course, that would be more or less big refactor, so another approach would be just waiting until Google thinks it gave enough competitive advantage to big vendors over small and finally releases 3.0+ source code, which supposedly implements wheel support.

Comparison of OpenSource PDF readers for Android

Today we're going to review few open-source PDF readers for Android platform. The table below provides links and feature-by-feature comparison, with more detailed discussion of features below the table. It should be noted that all these readers are based on the same PDF rendering library - MuPDF, so offer roughly the same rendering quality, the differences may be only due different version of the library used, or different configuration options (for example, some readers compile MuPDF without JPEG2000/JBIG support, or without standard PDF fonts).

The review summarizes with expectable conclusion - there's no perfect reader so far, but selects clear winner, which is worth to be hacked on.

Feature	DroidReader 0.5	APV aka PDFViewer 0.2.9	VuDroid 1.4	MuPDF Android Client 0.8.165
Builtin open file	-	+	+	-
On-screen zoom	-	+	+	+
Continuous pages	-	+	+	-
Page smaller than screen	- (force close on attempt)	+	-	-
In-app rotate	+	+	-	-
Go to page	+	+	+	-
Table of contents	-	-	-	-
Find text	-	+	-	-
JPEG2000/JBIG	- (doesn't recognize pdf)	+	-	+
Other formats	-	-	DJVU	-

• Builtin open file - whether you can start application and select file to view, or must have a compatible file manager and open PDF in it using "open with".
• On-screen zoom - whether you can zoom by direct manipulation on screen (like, pinch zoom, zoom in/out widgets) or need to go to menu. Needless to say, without on-screen zoom a reader is hard to use for real reading.
• Continuous pages - whether you see single page at time and need to use explicit next/prev page actions, or can just scroll a page away and see next/previous page. (Arguably, continuous page reading is easier and more productive.)
  
• Page smaller than screen - whether you can zoom out page so it is smaller than screen. For continuous pages reader, that would mean showing more than 2 pages at the same time on the screen. While this seems like neat feature, it actually just complicates real reading, when you need to take extra care to zoom back carefully after occasional zoom-in. (That's of course why most apps don't bother to implement it.)
• In-app rotate - whether app has own support for rotating pages, or relies on OS to support rotation. Got a vendor-crippled device without OS support for rotation? You're lost without in-app rotate, so that's boon.
• Go to page - basic navigation feature. That's not much convenient for real reading, but without this, you can't do any real reading at all.
• Table of contents - real navigation. For an app to be really usable, it must support this. Nope of apps in review does though.
• Find text - other very useful navigational feature. You hardly can read technical/reference docs without this.
• JPEG2000/JBIG images support - Apps which doesn't support these images format don't really support PDF, just some crippled subset of it.
• Other formats support: You found your perfect PDF reader? Congrats, now repeat that for all other ebook formats you use. Don't wanna waste time like that? Choose readers which support all reasonably similar formats. For already typeset ebook, there're actually two formats: PDF & DJVU, so good reader should support both. For TXT, HTML, CHM you indeed would rather look for different reader with different featureset.
  

And the winner is...

Based on the table above, the clear winner is VuDroid: it supports both typeset-ebook formats, PDF & DJVU, and has reasonable usability features (like has limit for page zoom out, as well as adjusts zoom on rotation). One serious, but easy to fix thing lack of JPEG2000/JBIG support (fixable by extending MuPDF config). Other thing it lacks comparing to APV is text find. Well, all readers in review lack ToC support, which a perfect reader must have. Back to VuDroid, it's UI is rather bare - there's no even About dialog, so you can't know that you're running VuDroid at all, or its version!

Weekend project: porting a game to QVGA

Following a mediaplayer, games would be next thing people ask for Angstrom. So, I decided to look what would be good candidates to add to feed. There're bunch of different games' recipes in OE, but I was thinking about some catchy, dynamic arcade. Of course, SuperTux came to mind! ;-)

OE already has recipe for SuperTux, and quick try in QEMU showed it works. In VGA mode. Attempt to run with QVGA screen resulted only in error that suitable video mode cannot be found. So, I decided to see if quick hack could solve this, and then document what it would take to do so.

Quick look at the source code showed that it is one of the critical cases of software engineering - 640x480 resolution is deadly hardcoded, with numeric coordinates spread around the code. Fortunately, short after I spent 10 mins figuring where to stuff divisions by 2, I googled for "supertux qvga". Hits followed! SuperTux was ported to GP2X and even to WinCE. I took GP2X version to look at.

GP2X port is nice produce of folks who have motivation to do something, but don't know what the diff is ;-). It was also done against SuperTux 0.1.3, while OE had 0.1.2. On the way, I bumped OE's version to 0.1.3 too, while finding that fixed-point patch for 0.1.2 no longer applies to 0.1.3 (will need to rediff). Finally, making diff out of GP2X version and cutting off changes related to autoconf-generated files, I got ~70K patch implementing --enable-320x240 and --enable-gp2x options (adding those was neat, unlike not producing a diff). Applying that patch on top of pristine 0.1.3 (with bitbake recipe of course!) and cleaning off some sloppy gp2x changes which were compiled in even though --enable-gp2x was not given, I finally got the package built. Quickly checking that it doesn't work in 240x320 mode, I had it run with xrandr applied, just to see garbaged fonts and graphics. Of course! Of course gp2x patch doesn't resize the original graphics on the fly, but expects it to be downscaled already, even though such gfx is not included in source archive. I pulled it from binary package though, and few minutes later saw the expected fun:


So, thank you scachi (Ingo Arndt) for doing all the fun work, and leaving dirty work of cleaning it all up to me! ;-D

On that route I proceeded, and next task was figuring out what to do with graphics. Having a binary drop of graphics was for sure no more acceptable than a complete source archive instead of diff. We talk port here, not something. I still don't target that at upstream, but not because it's not worth being there, but because it would be hard to explain what's it all about to people who write draw(537, 39) ;-(. Nonetheless, QVGA graphics must be produced from upstream version during build time. Just few days before I heard pH5 talking about imagemagick-native, so having checked it was not in OE (while target version was), I caught him on IRC to find out that it belongs to "would be nice to have" category. 15mins later it was there, fortunately "inherit native" was all needed for it.

My initial attempts at resizing original SuperTux graphics at 50% proved to give rather bad results, having size as big as original, or even bigger, and for sure much bigger than gp2x versions. But man'ing thru and recalling my old ImageMagick experience quickly gave its fruit by applying adequate color quantization after resize (I used --colors 64). Adding pngcrush-native and running magick's images thru it was final touch - in the end, I got image set ~30% smaller than gp2x's, while still looking better!

What's next? Too big a package. It would be nice to let people install this thing to flash, plus I target it for inclusion in LiveRamdisks, so 6.5Mb compressed package was not very bright. Glancing over data files shipped with SuperTux, it turned that music/ is nice candidate for slimming. First of all, there're few duplicate tunes, just one copy with "fast" suffix. Size was same, and diffing them, there were handful byte changed. Looking thru code, "fast" version is played when level's time limit is running out. I llluv that feature! But not at the expense of my flash ;-I. "fast" version went to /dev/null for the QVGA, and now, small-size version. Secondly, there was a credit.ogg file, which gp2x port replaced with some .xm. Trying .ogg still, I found that SDL can't scroll screen and play 160kbit ogg at the same time, on PXA 400MHz. So, bye, .ogg, good riddance! And thanks gp2x again for offering a replacement.

Now I finally decided to run game on full-fledged hardware - h4000, as earlier I ran it in QEMU and on h3900, which lacks audio. It immediately crashed on startup, complaining about not being bale to load a .mod music. A check of source, then libsdl-mixer recipe and - the latter has mikmod support disabled. Poor. With it on, I finally have a nice, commercial-grade arcade running on a Linux PDA! I even was able to quickly finish couple of levels, even though controlling PDA in a landscape position is not ideal.

Final touch I made was extracting bonus levels to separate packages. Level description are text files, taking more than a megabyte in raw size, but packages turned out to be ~50K. Well, let's save space for ext2 people nonetheless, and most importantly, have a complete experience of what it takes to produce a nice PDA port of a game.

So, that's how it was. I took time to write this long, if not detailed, description, in the hope that it will both motivate people to port games to OE/Angstrom, and will give hints how to do that. So, let's hope that people will care for their favorite OpenSource games, or choose to have such a weekend fun ;-). Otherwise, thinking about it, games are likely the best candidates for bounty-sponsored porting - after all, due to the manner many games are written, it's not too easy to port them to a lower resolution/smaller size/more CPU efficiency. So, if people want more fun, they should take the fun of doing a port (it's much more fun than playing a game itself, trust me ;-D ), or motivate other people who want to do that ;-).


Oh, and back to tux the super: the supertux-qvga recipe should land soon in OE. I hope to dump packages to unstable feed too. Then, there're following TODOs before it's perfect:

1. Forward-port fixed-point patch to 0.1.3 (I get ~25fps with sound, and that's not too much, and there's jerky scrolling sometimes).
2. There're few relatively big .mod's which are used relatively rarely. It would be nice to leave just a couple of smaller ones in a core package, to really slim it down, and put the rest in extra-music package.
3. Fully clean up gp2x patch, it's still too dirty.

Smallscreen mod for GtkFileChooser

OpenEmbedded have had smallscreen patch for GtkFileSelection widget for quite some time now, but unfortunately it doesn't affect usability of the most software, simply because many programs now use GtkFileChooser widget instead. GTK+ 2.12 manual also following about the matter: "GtkFileSelection has been superseded by the newer GtkFileChooser family of widgets."

Let's look how standard GtkFileChooserDialog looks on QVGA portrait device (240x320):



Note that "Places" pane on left cannot be shrinked beyond the size shown, which doesn't leave room for any useful display of filenames, so the dialog is clearly unusable.

So, I've took time to patch GTK+ 2.10.14 (this is the version used by Angstrom 2007.12, and my primary focus is to improve its usability on the supported devices) to make the widget be more PDA-friendly. I started with "data-driven" changes (meaning changing numbers and strings, but note code constructs):

• Reduced Gnome Human Interface Guidelines mandated spacing and borders of 6 and 12 pixels to 2. It's nice to have standards (even though Gnome doesn't offer us opportunity to choose from ;-) ), but on small screens, there's simply not enough space to spend pixel-wealth on gaps.
• Removed labels from Places pane's buttons, leaving only icons.
• Made Places pane shrinkable.
  

Even these changes made big difference, but stopping there would be to leave the dialog in barely usable state, and I'm really hope for a Linux GUI environment which is comfortable to use.

So, adaptive relayout was required, based on "PDA" mode being active. I first started with defining PDA mode as being portrait screen orientation, but thinking further, the problem, at least for GtkFileChooser, can be defined as follows: there's just too little of horizontal space available, and there should be efforts applied to use it to show as much of user's filenames' length as possible. Based on this note, PDA mode was defined as having a screen width below some threshold. This threshold was set as absolute value, but is not really arbitrary, and tied to real-world available screen sizes. I found that standard dialog looks pretty well in VGA landscape orientation, but still leaves too little space for filenames
in portrait orientation. So, threshold was set to 490 (to account for fudge factor ;-) ).

Now, with the above note on horizontal space scarcity, and keeping in mind that screen area at all is scarce, for vertical space should be saved too, following dynamic layout changes are done to dialog when being in PDA mode (i.e. run on the screen <490 pixels width):

• Vertical split pane is used for Places vs Filelist
• Buttons are packed to the left instead of bottom of Places
• Actually, only "Add" button was left, as "Remove" action can be easily accessed from Places list context menu, and most importantly, intuitively can be expected there. ("Add to shortcuts" choice is available for context menu on Filelist items, but who'd look for it there, without knowing it is?). This allows for more visually pleasing layout when Places pane is minimized.
• Dialog itself is sized to take all available width (originally, GTK+ sizes it to take no more than 3/4 of screen width, if possible, or packed requested size otherwise).
  

All in all, that's how the dialog looks now:


A refreshing change, with pretty long filenames being easily visible.

I've tested the patch pretty well, plus code changes are pretty small, so I intend to commit it to OE soon, and RFC its addition to Angstrom stable branch after it gets more review and testing.

There're still few things to consider and do to make it even more usable on small, PDA-like screens:

• Catch and process screen geometry change events - I'm pretty sure this is not done by GTK+ currently, and on dynamic screen device like PDA could make parts of dialog go offscreen when switching from landscape to portrait and vice-versa.
• Possibly, adjust screen width threshold based on more testing (original value was based on review of big-gaps dialogs, maybe smaller gaps affect that).
• Alternatively, gaps can be calculated on the fly, so original Gnome HIG-mandated values would be used on big screens, and small values only in PDA mode.
• Default "File system" choice in Places is superflous, it can be accessed with the icon from the path buttons at the top of dialogs. Unfortunately, screenshots above have it scrolled away. And having "File system" is Places causes exactly same problem: it takes space and calls for scrolling, so we'd better skip it there altogether, letting user to access own choices easier.
• Think about dialog height. Currently, as seen from above screenshot, it leaves bunch of screen area unused, and (apparently) due to Matchbox window management constraints, it cannot be resized by user. We could fit 1-2 more filenames if sized the dialog near-fullscreen. But that would look OK for QVGA, but already artificial for VGA.
  

Finally, it would be fun to have a look at GTK+ 2.12. As they say, it has stuff contributed by Nokia based on N770/N800 work, so I keep my fingers crossed that I didn't do monkey's job! ;-) Nonetheless, the focus is current Angstrom release, as I wrote above.

*Real* C#/Java support in OE

I finally found time to read Cliff Brake's excellent article summarizing his work on adding realy-working C#/.NET support to OE. Well written, it gives info why C# is useful choice for embedded systems, compares it to C and Python (great choices!) and details how to use it in OE. What of course would be *really* interesting to know is bug/feature (in the sense of performance, memory/disk footprint, compatibility with existing standards, etc.) comparison of current open-source C# and Java implementations, to be able to make choice for some new, independent project. Well, that's not going to be that easy so far.

One point where .NET has win over Java is "by default" portability/device coverage. It's pretty to write simple applications which run both on full-fledged .NET and CompactFramework, which means it's easy to develop small utils on desktop, and have them run without extensive debugging on PocketPC device. Back in the days I still bothered with trying to make PocketPC do what I need, that was a big win! Example of real-worldly usable app written in such way is here. Of course, back then, it was very hard to get full benefit of that opportunity, due to the way vendor provided toolset for .NET development - overloaded with GUIs and unimportant features, it possibly helped someone with a good favorite editor, but made integration work a great chore. Reading thru Cliff's article, one may once again rejoice that we have OpenEmbedded, which handles task of integrating 3rd-party dependencies into the project and complete deployable solution a breeze.


Returning back to Java, we are going to have fresh Java support too, thanks to the work of
Robert Schuster. Hope it will land soon in OE mainline, so the application developers/integrators for Angstrom, OpenMoko, etc. will have unprecedented choice of tools available at their fingertips!

It's all firefighting, right?

Well, time for a nice "depressive" post ;-).

So, at the beginning of week I decided to port GParted. Was more or less easy, just a fix for an obvious thinko from the author regarding C++ std namespace ;-). However, it failed on linking stage with infamous rpl_malloc() and friends not resolved for libparted. Looking thru cofigure log, that's of course result of crosscompiling assumptions, but OE has defines for the corresponding tests in autoconf site files, so what was actually happening is shipped parted 1.8.7's configure not loading these site files.

It also turned out that autoreconf'ing of this parted version doesn't work, as it requires autoconf 2.61 and friends as minimal, while OE has 2.59. Trying autoreconfing 2.61 (which is DEFAULT_PREFERENCE=-1 in OE) lead to the same issue with site files loading. At this point I submitted bugs on this, and raised issue on #oe. Actually I didn't even expect immediate big attention, but it caught developers' eye, and with the help of XorA and hrw, to the end of the day we had a solution. (And the root of issue was bug in autoconf 2.61. They used "shell programming patterns" (cough) you really don't want to use in your scripts, and the result is proverbial - they outslied themselves).

Well, on the droop of day, GParted was built. I run in QEMU and was surprised that UI was pretty barely usable on QVGA. Run on a real device to try a real card brought a gore however. First of all, GParted didn't detected my SD card at all. I even went looking at GParted source for how it scans devices, but then run parted on it. "Overlapping partitions now supported" was abort message. Overlapping partitions? Me? No! Wrong call! Fortunately, running fdisk showed instead of the senseless bold accusation the fact that my camera indeed tried to dig weird holes in parttable, apparently confused with ext2 partition there ;-)

Well, finally GParted was run, bliss. But just going thru menus once made them no longer accessible. Already trained on such stuff with LiveRamdisks work, I knew it's out of memory. Running ps aux showed some unusual suspects. Killing them (btw, GParted's RSS was "merely" 15Mb comparing to those 6Mb's. Ah, it's all shared libraries, ok, ok, I shut up.), I finally had the thing live. Now closer look look showed it doesn't recognize EXT2 partition (at least FAT it did). The same in parted. Have no idea is it camera hosed it or it's just proverbial GNU software quality. It also turned out that the only operation I was able to do is to change boot flag for a partition ;-). I tried to format unrecognized partition as EXT2 for example, and it failed after shuffling a card for a bit. Getting to HTML report it laid in the home dir surfaced "sh: nice: Command not found". Oh, oops, dear app ;-).

Finally, I wanted to make a screenshot, but gpe-scap failed to write it, complaining that it can't do UTF-8 -> ISO-8859-1 conversion for PNG CREATOR chunk (soft laugh).

---

So, what are the conclusions? X is not an ultimate solution, but merely an option. Lure to run large body of existing, and updated, software is still a lure, as besides this opportunity X brings bloat, which on resource-constrained system vice-versa inhibits ability to run all that wealth of soft well.

Also, all those kernel-hacking games are really old. And I hope that everyone on the block understands by now that what they get once kernel is well and polished is havoc in userspace (this applies to new players like Neo1973 too). So, it's time (yes, finally now, if not long ago)
to leave machine-level feudalism behind, and bring all Linux PDA/phone communities together, to work on common aims. And OE is well established community crossroad project, so implementation-wise, that would mean making sure that any more or less developed device is available in OE, and that any newcomer for a questions "Is X supported?" or "Where can I find stuff for X?" could be answered "Use OpenEmbedded." Yes, right that - use OpenEmbedded, period. Not even "You can use OpenEmbedded, just copy one to another one, and tweak this and that".