Setting default directory for screenshots in GNOME 3

Since gnome-screenshot doesn’t have a config panel of sorts, this has to be done via dconf-editor :-S

Using dconf-editor go to org/gnome/gnome-screenshot and type in whatever you like in the auto-save-directory value. I have entered the path to my Desktop. You might want to use a different directory – say: /home/you/Documents/Pictures. Feel free!

Using dconf-editor to configure where the screenshots are saved

Then close dconf-editor.

The key bindings for saving screenshots can be changed in the “Shortcuts” tab of Keyboard Settings. It’s actually quite easy, and I’m very glad of it, because as I’m using a Mac keyboard which doesn’t have the Print Screen key, the defaults didn’t work for me 🙂

Configuring shortcuts for screenshots

I configured it to save a screenshot with F14 –more or less where a Print Screen key would be! Shift + F14 for saving a selection only, ALT + F14 for capturing the active window.

It’s funny that these shortcuts end up being shorter than the equivalent defaults in Mac OS, specially if you also have to use the fn key to really use F3 as F3 and not as the show-me-the-Dashboard special key. For comparison, capturing the screen in Mac OS is done with ⌘ + ⇧ + F3 (plus possibly fn too), so you end up pressing 4 keys (unless you change it, of course!).

A hack to parse RSS feeds with php

Just happened to assemble this script hack recently, out of the requirement for a quick’n’dirty feed parsing feature:

$feed_contents = file_get_contents($feed_url);
$xml = simplexml_load_string($feed_contents, LIBXML_NOCDATA);
$feed_array = json_decode(json_encode($xml));
print_r($feed_array); // Surprise!!

Now this evidently is not SimplePie or Magpie RSS or whatever feed reader library tickles your fancy*, but assuming the feed will never be malformed, it can save you lots of time! Isn’t that what php was meant for? 😛
Continue reading “A hack to parse RSS feeds with php”

Fix the “fluxgui is already running, exiting” error

It seems fluxgui had crashed previously, or maybe I had killed it some days ago and forgot about it entirely. When I tried to restart it, it didn’t do anything. Launching it from the command line returned the “Fix the “fluxgui is already running, exiting”” message.

Looking at the most recent version of fluxgui code, I thought there would be some sort of .pid file in my home directory:

self.pidfile = os.path.expanduser("~/")

but I was wrong; there wasn’t any file in my directory. The git version is not the same that is published in the PPA, and as such there might have been some changes to where the PID file is saved.

I found mine was actually in /tmp, so the only thing I needed doing was deleting the file:

rm /tmp/

Obviously, unless your username is sole too, the name of your file will be different, so have a look at /tmp before trying to delete anything 😛

sole@courgette:~$ ls -l /tmp/flux*
-rw-r--r-- 1 sole sole 4 2011-08-01 08:21 /tmp/
-rw-r--r-- 1 sole sole 0 2011-08-01 08:21 /tmp/fluxlog.txt

Android’s activity stack and pressing HOME

I was having a huge issue with the application I’m working on. The idea is to have a MainActivity and a GameActivity; when you’re in MainActivity and click on a certain button, you get GameActivity. So far so good.

The problem was that if I pressed HOME and then clicked again on the application launcher, I was brought to the MainActivity instead of GameActivity. The expected behaviour by default in Android would be to return to GameActivity, which was the top activity in the application’s activity stack. So why wasn’t this working?

After looking for hours and reading in detail everything in the documentation regarding the activity section in the AndroidManifest.xml and tasks stack, I decided to dare ask my first ever Stack Overflow question, and went to sleep.

This morning, I found that two people had answered the question already. Yay! Unfortunately their answers were only tangentially related to my question. It’s amazing how complicated human language is: you ask something, people answer what they understand–and it might be completely different to what you meant to answer.

But I had earned an student badge and five points thanks to asking a question! Yay! Awesome! My reputation had increased to SIX points! Woooo!

Encouraged by this marvelous self-achievement, I decided to further pursue my quest for a proper answer, and I began to examine the list of questions related to my question. Lucky as I was, there was a particular one that answered mine!

So I have ended up answering my first ever Stack Overflow question, but I can’t accept my own answer yet. Booh!

However since this is my blog I’ll write my answer here and you’ll have to believe it’s the right one. So there we go.

And the Answer is…

I was launching the app by using IntelliJ, and it seems it launches the application in a different way than a user, clicking a home screen widget, would launch. It’s explained in the answer to another Stack Overflow question:

This is due to the intents being used to start the app being different. Eclipse starts an app using an intent with no action and no category. The Launcher starts an app using an intent with android.intent.action.MAIN action and android.intent.category.LAUNCHER category. The installer starts an app with the android.intent.action.MAIN action and no category.

So I’ve manually killed the application in the phone, and relaunched it again from the home screen widget. Then opened the GameActivity, and pressed HOME. Now, when relaunching it the GameActivity is still visible and keeping its UI state as it was when I left it.

And I guess that the reason why a new instance of the activity was created when pressing the shortcut before was due to a different Intent being used for starting the activity.

In other words: when things go awry with your activities, make sure you kill your application and start anew, launching it from the phone and not from your favourite development environment.

Now, I’m back to the code! \o/

How to hide the camera preview in Android

It actually was something that intrigued me to no end. No tutorial that I’ve read explained how to do it; there were only vague (and incorrect) mentions to not setting PUSH_BUFFERS in the SurfaceHolder, but yet there were apps who were totally hiding the camera preview, such as the famous “spy camera” style apps (those that look like an innocently looking web page but actually are recording everything). So there should be a way, and I just had to find it.

Continue reading “How to hide the camera preview in Android”