One thing that got my attention was “test-driven development”. In the past I didn’t really do serious software tests, i.e. regression and integration tests. Why? Because programmers are mostly lazy, and unit tests are somewhat boring to write.

But I realized I was completely wrong. When I began writing the first tests for FlexWorld (I removed everything before!) it actually felt quite good. The reason is the workflow: At first you write the tests for the interface you want to get (this implies thinking about it, which is very important). This also gives you practical use-cases. After that you implement the production code itself.

That happens step-by-step. For example for every single function you write a test, then the implementation. Thereafter you build and run the tests. If they pass and you’re somewhat sure your tests are complete and make sense, you KNOW your code is sane!

Before I’ve started with unit tests it always felt like: “Uh, this should work.. I will throw in some debug output messages and see if the result is something I expected.” But I was never sure if my code was sane completely. And when a bug happened, it felt normal to check the code, eventually run the debugger and see what was wrong.

I highly encourage everybody to TEST software and adapt the test-driven development workflow. It just feels better when you add a feature and know it doesn’t break anything.

To make it work again you probably have to rebind the TapButtonX settings that are set to 0.

synclient TapButton1=1 TapButton2=2 TapButton3=3

Add it to your session start-up file for persistence. Also check out gpointing-device-settings for various touchpad options.

To be able to concentrate on development and buy things like graphics, 3D models etc., I also decided to start a campaign at IndieGoGo. If you like what you see there, please spread the word!

gtk-recordmydesktop completely sucks when it comes to selecting your audio device. Normally accesible by the ALSA descriptor “hw:1″, recordmydesktop wasn’t able to use it. Istanbul completely failed to render the audio part.

So after some googleing I found out about the perfect solution: ffmpeg and jack_capture. I wrote a little script that combines the steps involved. Here it is:

#!/bin/sh

DATE=`date +%Y%m%d`
TIME=`date +%Hh%M`

ffmpeg -an -f x11grab -r 20 -s hd720 -i :0.0 -vcodec libx264 -vpre lossless_ultrafast -threads 4 video_$DATE-$TIME.mkv &
jack_capture --port system:capture_1 audio_$DATE-$TIME.wav

At first it runs ffmpeg in the background. Be sure to adjust the parameters if you’re adopting it. Then jack_capture is launched – again, take care of parameters for your system (especially the Jack port). Of course you need to startup Jackd before you run the script (can be easily done through qjackctl normally).

jack_capture is also capable of saving directly to MP3s, however it must be compiled with the proper support, and on Debian it isn’t (due to MP3 licensing problems). Converting however isn’t a problem at all, just invoke: (of course now you really need liblame or similar; for Debian see the Debian Multimedia Library)

ffmpeg -i my_audio_file.wav encoded.mp3

Normally this produces a high-quality MP3 – if not, adjust settings (see “man ffmpeg” for help).

The last step is muxing both streams, so that you’re left with only one file. Again we use ffmpeg for that (make sure you have the MP3 ready!):

ffmpeg -i audio.mp3 -i video.mkv -acodec copy -vcodec copy my_final_video.mp4

The video and audio streams are simply copied to the target file. What comes out is a high-quality video/audio file, congratulations.

One note on possible syncing problems: Since ffmpeg (the capturing part) and jack_capture are launched after each other, there may be a delay of some milliseconds. In my tests I wasn’t able to recognize it. But this may depend on your system.

First step: Install iTunes and do the recovery there. It even started but did never complete, the progress bar got stock at 100%. So I did something that you normally never ever do: Disconnect the device while there’s an operation pending. Result: Device did not turn on, now it really seemed dead.

So I googled for solutions and found out about the “iPod Reset Utility“, a small tool by Apple to reset iPod Shuffle devices. I started it and — wasn’t it expected? — an error message telling me “Only for 32 bit systems” appeared. Holy cow… I was using Windows 7 64 Bit, but the architecture wasn’t the problem, it’s the tool’s installer’s compatibility checking routine that’s yelling. So I tried Virtual PC with Windows XP mode which told me my CPU isn’t setup for virtualizing (yeah, sure! BIOS setting “AMD virtualization” = ON). Windows’s compatibility mode settings didn’t work either.

Then I did what I usually do when a Windows program has problem with its own operating system: Boot Linux (again) and do it right! I started the iPod Reset Utility setup using Wine, installed it successfully and tried my luck again. Unfortunately the tool wasn’t able to detect the Shuffle in Linux. So I copied the files over to my Win 7 box, booted the evil Windows again, moved the iPod Reset Utility files exactly to the place where I’ve installed them on my Linux box and set the compatibility settings of Windows to Windows XP Service Pack 2.

Luckily the program started! I reconnected the iPod and surprise surprise, the tool recognized it and started the recovery!

So for anyone running Windows newer than XP Service Pack 3 with problems installing that tool, I packed the raw files for you. Just make sure to unpack them in the <Programs>/iPod/iPod Reset Utility directory and set the compatibility mode to Win XP SP 2 (rightclick on exe file, compatibility).

Download Apple iPod Reset Utility (unpacked)

Conclusion:

• Apple: Shame on you for providing an installer with silly OS version checks.
• Windows: Shame on you for bad downwards compatibility and not detecting virtualization.
• Linux: Thank you, keep it going.

Vim is not hard to use

Let’s begin by claiming “Vim is not hard to use”. At first we need to think about why someone declares something being difficult. In my opinion the reason is that someone is

• just not used to it or
• it’s incredible difficult to learn (lack of documentation, bad user interface, you name it).

The first argument might be the more important one: The average user started his computer career either with DOS or Windows, so using editors like edit.exe and notepad.exe was the usual business. You had (or have) the cursor and just type in characters. Easy!

The second argument, especially lack of documentation, comes to the table when you’re at least trying to learn a new program. When you’ve got a problem, you normally look it up in the docs, find your problem and answer and go on.

Back to Vim: Indeed you’re probably not used to it (hence you would already use it and would have never stopped doing so) and you think it’s difficult to learn. But that’s not true: Every single bit in Vim is well documented. You have several commands and tools that are just there to get you to the right point in the help pages. And not being used to something is really no argument to declare something as being hard to use.

Your editor is hard to use!

I’ve been using Vim for about 3 years now — and not just for programming, but whenever I’m about to write or edit text. And from that point of view, I tell you: Your editor is hard to use (except it’s vim, of course). Let’s talk about the why:

Computer programs are there to assist you in doing things, that means making your life easier and more comfortable. But in God’s name, how does an editor that has nearly zero features enhance your editing experience? I’m not (only) talking about notepad.exe here, that counts for editors like Scite, Notepad++, UltraEdit, Visual Studio etc. too.

You may argue that your editor has syntax highlighting. Good, but it doesn’t assist you with editing. You have folding. Doesn’t assist. You have tabs. Don’t assist. You have refactoring tools. Do assist, but may only work for specific programming languages. You have IDEs  with SCM integration, database connections, debuggers and tons of other tools and add-ons: They do not assist you with editing, plus there’re the native tools that already do those jobs fine.

I admit that I’m flaming a lot up to here, but let’s make things clear for now: Your average editor is just bad (focus on editing!). And please be honest: What else than moving your cursor around a lot combined with Ctrl+arrow keys do you do in your editor?

What makes Vim different — and better

The most important thing with Vim is what also confuses the most people: Vim does not only wait for your keystrokes and write the proper characters down. Instead, and this is important, it waits for your commands. You tell Vim what to do, and it will be done. Of course this implies that you know what you’re doing.

Basically vim is divided into 3 major modes:

• Command mode (or ex mode): Nearly all keys on your keyboard are bound to an action that Vim executes. In addition you can perform : commands.
• Visual mode: For selecting text, with the power of Vim selectors.
• Insert mode: This is what you mostly have in all other editors: You type, Vim writes it down.

We could say that if you don’t care of Vim’s features, just enter insert mode by hitting the i key and start typing. But of course you don’t want to do that, because you want to learn how Vim works, and not how you can continue using other editor’s habits.

As this article is not a Vim tutorial, let’s get back to the principles: I told you in the headline what makes Vim better, and the separation into several modes is the basic and powerful idea. Isn’t it just more logical to tell the editor “Hey, delete the next 3 words!” or “That line I wrote is stupid, delete it and let me type a new one!”? Why should hitting backspace for 70 times be more intuitive (yeah, you can also do Shift+Home, then Delete)?

Some other examples to get you an idea: “Delete the next whole code block”, “Increment the number under the cursor”, “Insert some text at the same place in 10 rows”, “Delete the line under the cursor and paste it below the next one, thus swapping them”, “Find the next occurence of the word under the cursor”, …

Hopefully you’ve recognized the difference: You’re invoking commands, you tell the editor what to do. You are not just moving the cursor around and delete here, insert there, catch the mouse and click everywhere.

How do I get used to all those keystrokes?

Seriously that’s the most heard excuse of users who stop to use Vim after trying it for 2 minutes. Again, you need to get used to it, which implies learning how Vim works. Luckily you only need a few keystrokes to get you started in a good way.

The first thing you should do is the so called vimtutor, a tutorial-like Vim introduction that shows you the bare basics. Just run vimtutor (.exe) and read(!) the instructions. After that my personal suggestion is: Use Vim! Just don’t stop, else you’re not getting used to it.

Once you’ve conquered the magic boundary of frustration, you’ll get enlightened by the pure power. Sidenote: I needed 3-4 approaches until I’ve continued using Vim for all my editing tasks, just be patient.

Whenever you feel like “That must be easier to do!” open up the help and specify your keyword (by issuing :help in command mode), or use the mighty :helpgrep command which searches the help pages for a regular expression (e.g. :helpgrep *delete*).

Another very good source are the Vim tips. Several Vim users demonstrate quite useful commands and keystrokes that make life a lot easier. However, do not (I repeat, do not!) try to learn all possible keystrokes at once. It’s a common mistake Vim newbies do. Just learn/lookup what you need or what you think might be done in an easier way. Following this approach makes your Vim experience a step-by-step learning curve.

Conclusion

Throw away your old habits and try out Vim. From someone using it for several years just believe the fact that it’s worth it. Be patient and you will edit your texts and codes much more effective in the future.

But please do not say “Vim is hard to use” anymore. If you do it nevertheless, then you got frustrated because of your old habits. It’s okay, just wait 1-2 days and try it again.

And before you can say knife, you’ll start to use Vim’s keystrokes and commands intuitively. As soon as that happens, you’ll feel pure fun when editing text and you’ll recognize that you’re so much more productive. Promises!

Last, but not least: Do not use emacs. Great operating system, but lacks a good editor. Try out Debian GNU/Linux instead and use Vim. Have fun!

Instead of YAML, you’ll get a very easy-to-understand theme syntax like:

Button.Normal.BackgroundColor = #123456
Button.Prelight.BackgroundColor = #789abc
...

Very intuitive to write and gives you everything you need to define and load themes. However I’ve designed the loader interface flexible enough to punch in your own loaders (YAML, XML, whatever). Checkout the Git repository to see the changes — the (working) YAML  code can be found in the separate branch called yaml.

You can find the Git repository here: https://github.com/TankOs/SFGUI