Switching Xfce to use metacity

I am trying out Xfce and liking it. However, I’ve never found a window manager better than Metacity, so I’d like to use it.

Here’s how I switched:

# Install it
sudo apt-get install metacity metacity-themes

# Tell it how many workspaces I want
gsettings set org.gnome.desktop.wm.preferences num-workspaces 9

# Of course, put my maximise, close buttons etc. in the right place
gsettings set org.gnome.desktop.wm.preferences button-layout ':minimize,maximize,close'

# See what themes are available
ls /usr/share/themes/

# Set the theme I want
gsettings set org.gnome.desktop.wm.preferences theme Dopple

# Try it out immediately
metacity --replace

# Make the change permanent, log out and edit
# ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml
# and change this line:
#  <property name="Client0_Command" type="empty"/>
# to this:
#  <property name="Client0_Command" type="array"><value type="string" value="metacity"/></property>

Java game programming: image rendering hints make no difference to rendering time

I am writing an Open Source/Free Software Java desktop game (Rabbit Escape) and am experimenting with allowing you to zoom in so that the images being rendered are fairly big, and I’m seeing some slow-down.

[Note: Rabbit Escape is also available on Android, where it appears to have no problems with rendering speed…]

To speed it up, I have been experimenting with passing various values to Graphics2D‘s setRenderingHint method.

My conclusion is that on my platform (OpenJDK Java 7 on Linux) it makes no difference whatsoever. Please leave a comment if I’m doing it wrong.

I am timing how long each frame takes to render, and comparing the time when I insert this code before my rendering code:

// As slow and high-quality as possible, please!
g.setRenderingHint( RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON );
g.setRenderingHint( RenderingHints.KEY_ALPHA_INTERPOLATION, RenderingHints.VALUE_ALPHA_INTERPOLATION_QUALITY );
g.setRenderingHint( RenderingHints.KEY_COLOR_RENDERING, RenderingHints.VALUE_COLOR_RENDER_QUALITY );
g.setRenderingHint( RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY );

with inserting this before my rendering code:

// As fast and low-quality as possible, please!
g.setRenderingHint( RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_OFF );
g.setRenderingHint( RenderingHints.KEY_ALPHA_INTERPOLATION, RenderingHints.VALUE_ALPHA_INTERPOLATION_SPEED );
g.setRenderingHint( RenderingHints.KEY_COLOR_RENDERING, RenderingHints.VALUE_COLOR_RENDER_SPEED );
g.setRenderingHint( RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_SPEED );

[Documentation, such as it is, is here: RenderingHints.]

I see no appreciable difference in rendering time or image quality between these two setups, or when I leave out the calls to setRenderingHint completely.

Platform details:

$ java -version
java version "1.7.0_75"
OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-1~trusty1)
OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)

fetchmail complaining about GoDaddy SSL certificate

Update: I don’t think this fixed the problem

I was getting this every time I ran fetchmail.

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: Broken certification chain at: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about.  For details, please see the README.SSL-SERVER document that ships with fetchmail.
fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
fetchmail: Server certificate verification error: certificate not trusted
fetchmail: Server certificate verification error: unable to verify the first certificate
fetchmail: Warning: the connection is insecure, continuing anyway. (Better use --sslcertck)

I appear to have fixed it by running:

sudo c_rehash

I found this by reading the documentation on --sslcertpath in the fetchmail man page. (As the error message told me to…)

Encapsulation as passing on responsibility

I recently dealt with some code that I felt was not properly encapsulated, but in a sense that I’ve not seen articulated in this way before. Please enlighten me if I missed it.

Here’s a snippet:

OutputThing manipulate( InputThing input )
{
    ProcessingThing proc( input );
    moreProcessing( proc.intermediateResult, input );
    return OutputThing( proc );
}

This function takes in some input and returns some output, using a ProcessingThing to do some work.

I needed to make a change to ProcessingThing to support some functionality, and I fell foul of something I didn’t expect.

I wanted to transform my input a bit, and wrote that code inside ProcessingThing. What I didn’t expect was that the untransformed input would later be used (in the moreProcessing call). The moreProcessing code failed because the transformation I had done made the ProcessingThing inconsistent with the InputThing.

Obviously, I should have checked more carefully.

But, it struck me that there is a pattern here. We are processing something by passing it from step to step in a “production line” of code. By re-using something from an older step, we violate this metaphor of passing on responsibility, because suddenly there are two copies of our input – it wasn’t passed on at all.

This feels a bit like we’ve violated the encapsulation of input by ProcessingThing, but maybe I’m stretching the word encapsulation too far?

I feel like if ProcessingThing properly encapsulated the details of InputThing, we wouldn’t need to re-use input later.

In fact, the fix in my case was to put the moreProcessing logic into ProcessingThing, meaning there was no need to refer back to the original input. I think this supports the argument that we are talking about encapsulation.