Entertain your baby using your Android phoneLast night my friend and I uploaded the first version of Baby Distraction, an Android app featuring charming cartoon animals, vibration and sounds.
I helped almost exclusively in an advisory capacity, but still am inexplicably proud of the result: it’s incredibly simple, but polished, and, most importantly, their baby loves it.
This morning I searched for “baby games” on the Android Marketplace, and it was the top hit. Fame and fortune await.
rdesktop swallows keyboard eventsThe Linux remote desktop client rdesktop grabs all keyboard events by default, which is good, because it allows e.g. you to Alt-Tab between applications and Ctrl-Alt-Del as if you were in front of the remote machine.
However, it is also bad because you can’t use the standard keyboard shortcuts to switch between virtual desktops. Varius Googling had convinced me that this problem was not soluble, since X only provides a global keyboard-grabbing function XGrabKeyboard, and once the event has been grabbed and fed to rdesktop, there doesn’t appear to be a way to re-emit it back up to the window manager so that it can be used to switch desktops.
Kudos to Sunner, therefore, for coming up with a workaround. It’s really simple: you have to press the key twice, and the first time, rdesktop simply ungrabs the keyboard. The second time, the window manager receives the event as normal.
Here’s my version of Sunner’s patch, against rdesktop 1.6.0. It removes Alt-Tab support since I don’t need that, and adds Ctrl-Alt-Up and -Down, because I do need those:
Share on Mastodon
--- rdesktop-1.6.0/xkeymap.c 2011-07-06 12:49:01.000000000 +0100
+++ rdesktop-1.6.0-mod/xkeymap.c 2011-07-06 11:40:24.000000000 +0100
@@ -598,6 +598,25 @@
ui_seamless_toggle();
break;
+ case XK_Left:
+ case XK_Right:
+ case XK_Up:
+ case XK_Down:
+ if ((get_key_state(state, XK_Alt_L) || get_key_state(state, XK_Alt_R))
+ && (get_key_state(state, XK_Control_L)
+ || get_key_state(state, XK_Control_R)))
+ {
+ /* Ctrl-Alt-Left/Right/Up/Down:
+ * Ungrab the keyboard so that user can use Windows manager's hot keys */
+ extern RD_BOOL g_fullscreen;
+ if (g_fullscreen) { /* Turn to normal window. Otherwise, rdesktop will be always on top */
+ xwin_toggle_fullscreen();
+ }
+
+ XUngrabKeyboard(g_display, CurrentTime);
+ return True;
+ }
+ break;
}
return False;
}
(Download it here: rdesktop-1.6.0-ungrab-on-ctrl-alt-direction.patch)
And as usual here is how to patch your Ubuntu system to include this patch:
sudo apt-get install build-essential fakeroot dpkg-dev sudo apt-get build-dep rdesktop mkdir tmp cd tmp apt-get source rdesktop cd rdesktop-* wget http://www.artificialworlds.net/blog/wp-content/uploads/rdesktop-1.6.0-ungrab-on-ctrl-alt-direction.patch patch -p1 < rdesktop-1.6.0-ungrab-on-ctrl-alt-direction.patch dpkg-buildpackage -rfakeroot -b cd .. sudo dpkg -i rdesktop*.deb
Now someone just needs to add support for reading your window manager settings to determine automatically what shortcuts you use to switch desktops, and/or support for a config file listing keys that make rdesktop ungrab the keyboard.
Reclaiming desktop space with Ubuntu’s window-picker-appletFor a long time I’ve customised GNOME to have a vertical task bar on the left and launcher buttons across the top. I’ve struggled with a long-standing bug with using a vertical panel, and I’ve sacrificed quite a lot of screen space to make enough room to see the window titles.
Recently I’ve found myself using smaller screens, and finding certain aspects of the Ubuntu Netbook Remix quite good. In particular, I like the combination of Maximus and window-picker-applet, which I combine with GNOME Do. This setup allows me to have almost all of my screen set aside for programs I am using, without feeling lost or inconvenienced.
I need one setting to prevent Maximus from automatically maximising windows – I just want it to remove the title bar when a window is maximised, because window-picker-applet shows the title in my panel instead:
and then I add Maximus to my Startup Applications (Click Add, give it a name, and set command to “maximus”), and set GNOME Do’s “Start GNOME Do at login” preference (the Preferences screen can be found on the drop-down at the top right of the GNOME Do window).
Now I am happy, except for a little bug fix and visual tweak I want for window-picker-applet. The relevant bugs are Bug #425813 (see my patch at the bottom) and Bug #798197. On an Ubuntu system it’s amazingly easy to use a patched version:
Switching workspace in GNOME via the command lineI use rdesktop to connect to some Windows machines, and it works beautifully. I like to allow it to grab keyboard input so I can switch and close windows on my Windows desktop without fear of accidentally doing something to the rest of my Linux desktop.
However, I have never found a way of letting some keystrokes escape – specifically Ctrl-Alt-Left, Right, Up, Down so that I can switch workspaces (virtual desktops) away from the workspace containing rdesktop.
I have finally found what I hope is a good workaround – I have installed easystroke and defined some mouse gestures I can use to switch desktop. These mouse gestures are not swallowed by rdesktop, so they still work, even when it has focus.
When I asked easystroke to send the Ctrl-Alt-Left etc. keystrokes, they got swallowed by rdesktop, so all I needed to be able to do complete the story was a command-line tool to switch workspace.
That turned out to be trickier than you might imagine, but here is my solution, using the amazing wmctrl.
This should work on GNOME with the metacity window manager, and the standard GNOME workspace switcher. It should be easy to adapt to other window managers and workspace tools.
First, install some tools. On Ubuntu you need:
Now create a file with gedit ~/bin/workspace-switcher & and edit it to look like this:
#!/bin/bash
CMD="$1"
NUM_WORKSPACES=`gconftool-2 --get /apps/metacity/general/num_workspaces`
NUM_COLS=`gconftool-2 --get /apps/panel/applets/workspace_switcher_screen0/prefs/num_rows`
NUM_ROWS=`echo "$NUM_WORKSPACES / $NUM_COLS" | bc`
CURRENT_WS=`wmctrl -d | grep \* | cut -d " " -f 1`
MOVE_LEFT="- $NUM_ROWS"
MOVE_RIGHT="+ $NUM_ROWS"
MOVE_UP="-1"
MOVE_DOWN="+1"
case $CMD in
"Left" )
NEW_WS=`echo $CURRENT_WS "-" $NUM_ROWS | bc`
if [[ $NEW_WS -lt 0 ]]; then NEW_WS=$CURRENT_WS; fi
;;
"Right" )
NEW_WS=`echo $CURRENT_WS "+" $NUM_ROWS | bc`
if [[ $NEW_WS -ge $NUM_WORKSPACES ]]; then NEW_WS=$CURRENT_WS; fi
;;
"Up" )
WS_COL=`echo $CURRENT_WS "%" $NUM_ROWS | bc`
if [[ $WS_COL -eq 0 ]]; then
{
NEW_WS=$CURRENT_WS
}
else
{
NEW_WS=`echo $CURRENT_WS "- 1" | bc`
}; fi
;;
"Down" )
NEW_WS=`echo $CURRENT_WS "+ 1" | bc`
NEW_WS_COL=`echo $NEW_WS "%" $NUM_ROWS | bc`
if [[ $NEW_WS_COL -eq 0 ]]; then NEW_WS=$CURRENT_WS; fi
;;
* )
NEW_WS=$CMD
esac
wmctrl -s $NEW_WS
Make it executable with chmod +x ~/bin/workspace-switcher and make sure ~/bin is in your PATH.
You can run it like this:
to move left – the other possiblities are, obviously, Right, Up and Down.
Or like this:
to move to a workspace by number.
If you want to use it with easystroke, create an action, and for the command simply enter switch-workspace Left and similar as the command.
Easystroke can be installed on Ubuntu like this:
Anatomy of an interpreter: the EvaluatorPosts in this series: Lexer, Parser, Evaluator
I’m still really enjoying writing my Scheme interpreter Subs, which can now succesfully run all the example code from SICP up to section 2.3.4. I’ve made the changes I mentioned I would in the Lexer article, so now the Lexer returns Tokens that contain information about their basic types, and I’ve gone through a significant refactoring to replace one of the several massive switch statements with a virtual function call (Martin Fowler would be proud).
Last time I explained how the Parser takes the stream of tokens coming from the Lexer and returns a hierarchical tree of Values, each of which represents an operation or thing in the program.
The Evaluator takes in a tree of Values, “evaluates” it, and returns another Value object, which is the answer. The Evaluator class is by far the most complex part of Subs, so in this post we’ll start with an overview of how it works. Future posts will break down the different parts in more detail.
The most interesting parts of the Evaluator class interface look like this:
class Evaluator
{
public:
std::auto_ptr<Value> EvalInContext( const Value* value,
boost::shared_ptr<Environment>& environment );
};
The EvalInContext method takes in a Value to evaluate, and an “environment” *in which to evaluate it. Note that the in the real code it takes a couple more arguments, including a mysterious and annoying boolean called is_tail_call which will be explained later.
* More on environments later. All you need to know for now is that they provide a way of keeping hold of all the things we currently know about, identified by name.
A very simplified version of EvalInContext would look like this:
std::auto_ptr<Value> Evaluator::EvalInContext( const Value* value,
boost::shared_ptr<Environment>& environment )
{
if( is_symbol( value ) )
{
return eval_symbol( value, environment );
}
if( !is_combination( value ) )
{
return auto_ptr<Value>( value->Clone() );
}
const CombinationValue* combo = to_combination( value );
CombinationValue::const_iterator it = combo->begin();
auto_ptr<Value> evaldoptr = EvalInContext( *it, environment );
if( special_symbol( evaldoptr ) )
{
return process_special_symbol( evaldoptr, combo );
}
else
{
++it;
CombinationValue argvalues;
for( ; it != combo->end(); ++it )
{
argvalues.push_back( EvalInContext( *it, environment ).release() );
}
return run_procedure( evaldoptr.get(), &argvalues, *this, environment );
}
}
If the Value to be evaluated is just a symbol, we call eval_symbol which basically looks up the symbol’s name in the environment and returns the value it finds.
If the Value is not a combination (i.e. the root of a tree of other values) it must be a basic type such as a string or an integer. In this case we simple copy the Value and return it.
Otherwise, it’s a combination. To evaluate a combination, we follow the “eval-apply” pattern. The principle is to evaluate all the Values in the combination separately, and then “apply” (run) the first value (the “operator”) as a procedure, using the other values as arguments. The first value must evaluate to something that is recognisable as a procedure, or this doesn’t make sense and we will throw an error.
In practice it’s a tiny bit more complicated. We evaluate the first Value in the combination (by calling EvalInContext recursively), then we check whether it’s a special symbol such as if or let and if so, deal with it separately. Otherwise, we evaluate all the other Values (calling EvalInContext recursively again) and put them into a new CombinationValue, and pass the operator and the arguments to run_procedure, which looks something like this:
std::auto_ptr<Value> run_procedure( const Value* operator,
const CombinationValue* args, Evaluator& ev,
boost::shared_ptr<Environment>& environment )
{
if( is_builtin_procedure( operator ) )
{
return handle_builtin_procedure( operator, args, environment );
}
else
{
std::auto_ptr<Value> ret;
const CompoundProcedureValue* proc = to_compound_procedure( operator );
boost::shared_ptr<Environment> new_env =
proc->ExtendEnvironmentWithArgs( args );
for( CombinationValue::const_iterator it = proc->GetBody()->begin();
it != proc->GetBody()->end(); ++it )
{
ret = ev.EvalInContext( *it, new_env );
}
return ret;
}
}
Running a procedure means either doing something built-in (for example adding up two numbers and returning the result) or evaluating some other code, which comes from the definition of the procedure being run. First we call ExtendEnvironmentWithArgs to create a new Environment, which contains the argument Values that were supplied, and then we loop through all the sections of the body of the procedure, evaluating each one. Note that we throw away the returned Values for all sections except the last one (this is how Scheme works).
Once we’ve evaluated and applied our procedure, which of course potentially includes numerous recursive calls to EvalInContext, we end up with a Value that is returned, and we’re done.
Simple eh?
But now I must make a confession: almost everything I have written above is lie. Why would I lie to you? Because I missed out something wonderful and strange called “tail-call optimisation”. I’ll explain next time.