<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<!--
finger is on while button is up
-->
<item android:state_checked="false" android:state_pressed="true"
android:drawable="@drawable/ic_btn_medium_grey"/>
<!--
finger is gone, button is up, default
-->
<item android:state_checked="false" android:state_pressed="false"
android:drawable="@drawable/ic_btn_light_grey"/>
<!--
finger is gone, button is down
-->
<item android:state_checked="true" android:state_pressed="false"
android:drawable="@drawable/ic_btn_dark_grey"/>
<!--
finger is on while button is down
-->
<item android:state_checked="true" android:state_pressed="true"
android:drawable="@drawable/ic_btn_deep_dark_grey"/>
</selector>

If you are unsure why you want to have four states for a single button just imagine the button can stay in its checked state.

Example 1: The commit P, Q, R which are contained in branch feature should be copied to branch master. The commits should be appended to commit M.

The first command git rebase --onto M O R copies the commits P, Q, R to the branch master. They won’t be visible if you check the visual graph in gitk. This is because there is no branch reference that points to one of the three commits. To update the branch master run the second command git rebase HEAD master which moves up the HEAD to commit R.

Example 2: The second scenario is similar. It concentrates on two things: 1) You can choose any destination commit as the root for the copied commits. In this case I have chosen commit L as the root commit. 2) As in the first example you need to apply a branch name to the last commit of the group after you did the actual copy operation in order to let the commits become visible.

At the point when you understand the three arguments in general it will be much easier to use this command in various situations. Therefore, memorize the following:

git rebase --onto argument1 argument2 argument3

• argument1 is the destination commit for the copy operation.
  It will be the predecessor of the commit subsequent to argument2.
• argument2 is the predecessor of the first commit of the range that will be copied.
  argument2 itself will not be copied, though.
• argument3 is the last commit of the range that will be copied.

Further information can be found on the man page of git rebase.

Eclipse – Tooltip with default colors settings

When autocompletion popup appears the first suggestions is not readable at all.

Eclipse – Autocompletion with default colors settings

So, here is what you need to do to fix the colors.

Fixing the color settings

Create configuration file in your HOME folder. The name is not essential, mine is named .gtkrc-eclipse

# Customs color settings for Eclipse.
# Load Eclipse as follows:
# GTK2_RC_FILES=~/.gtkrc-eclipse eclipse
#
# Sources:
# http://askubuntu.com/a/131348/18533
# http://stackoverflow.com/a/8063723/356895
# http://askubuntu.com/a/70964/18533

# Autocompletion background color.
style "eclipse-autocompletion" {
base[ACTIVE] = shade(0.7, "#F2F1F0")
}

# Tooltip background color.
style "eclipse-tooltips" {
bg[NORMAL] = "#e8e8e8"
fg[NORMAL] = "#000000"
}

# Load settings.
class "GtkTreeView" style "eclipse-autocompletion"
widget "gtk-tooltip*" style "eclipse-tooltips"

To load the settings whenever you launch Eclipse from the command line simple alias the original binary and preload the settings file.

alias eclipse='GTK2_RC_FILES=~/.gtkrc-eclipse eclipse'

Further, if you use the launcher within Ubuntu, you need to modify the .desktop file for Eclipse, too. You can find the file in ~/.local/share/applications.

/bin/bash -c "GTK2_RC_FILES=~/.gtkrc-eclipse eclipse"

When you are done and restart Eclipse the autocompletion and the tooltip should look similar to the following screenshots. I have chosen a light gray for the background color of the tooltip window. Feel free to customize the colors to your own taste.

Eclipse – Tooltip with default colors settings

The first tooltip suggestion should be readable now.

Eclipse – Autocompletion with fixed colors settings

I compiled this article from various sources which I like to add as a reference.

• http://askubuntu.com/a/131348/18533
• http://stackoverflow.com/a/8063723/356895
• http://askubuntu.com/a/70964/18533

Update: I noticed that TeX Live 2012 has been made available via apt-get. I recommend testing it out (I haven’t done so yet).

1. Open vim while loading all relevant files recursively as a argument list the editor. vim **/*.txt
2. Start recording a macro in register “a”. Type qa
3. Enter the substitution command to search and replace a specific character pattern :%s/re\-use/reuse/ge
4. Change to the next file in the argument list. Type :wnext
5. Stop recording the macro in register “a”. Press q
6. Playback the macro 999-times by entering. 999@a

The posts “Vim 101: Search and Replace on Multiple Files” and “Vim. How to replace a word (string) in several files.” guided me. Please have a look there for further information.

Although, the add-on seems to be outdated to work with the latest Thunderbird version (which is 10.0 right now) there is an easy way to install the add-on while the automatic installer refuses to do so. Here is what you can do to make the installation work.

1. Download the Colored Diffs *.xpi file
2. Open the archive with an archive manager of your choice
3. Edit the contained install.rdf with a text editor of your choice
4. Change the maxVersion parameter to be equal or greater then the current version of Thunderbird
   Before: <em:maxVersion>3.1.*</em:maxVersion>
   After: <em:maxVersion>13.1.*</em:maxVersion>
5. Save the changes and store them back into the archive
6. Install the add-on

Do not forget to check out the preferences after you installed the add-on. You can choose 4 different types to display the diffs and customize the colors as well.

If you feel interested to enhance the add-on you can do so. The “Colored Diffs” project is hosted on google-code open for people to participate.

git add file
git commit --amend

In case you do not wand to change the commit message there is the new option –no-edit for git commit introduced in git 1.7.9. The git release notes describe how the –no-edit option can be used.

“git commit –amend” learned “–no-edit” option to say that the
user is amending the tree being recorded, without updating the
commit log message.

git commit --amend --no-edit

Of course, I added an alias for the new option to my global git configuration.

ci = commit
cm = commit -m
ca = commit --amend
cn = commit --amend --no-edit

⚡ git cm 'Initial import.';
[master (root-commit) 0396c37] Initial import.
Committer: User User@Machine.(none);
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name ''Your Name''
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file

Well done git!

NSLog auto completion

Please follow these steps to add the code snippet to the scripts in Xcode 4.

1. Copy and paste the following code into your editor. Anywhere.
   NSLog(@"%@ %@", self.className, NSStringFromSelector(_cmd)); /* DEBUG LOG */
2. Open up the code snippets library which sits in the utility pane on the right side. Look for the curly braces {}.
3. Highlight the above mentioned code – click and hold the mouse over the text  (for a short while) – drag them into the code snippet library.
4. Afterwards you can edit the snippet and add a title, summary and a completion shortcut. I used the following settings:

                 Title: Custom NSLog (Class & method name)
               Summary: NSLog prints the class and method name
              Platform: All
              Language: Objective-C
   Completion Shortcut: NSLog
     Completion Scopes: All

Custom NSLog snippet

You are welcome to comment and post your custom code snippets!
This article is inspired by the post “Easy Doxygen code snippets for Xcode 4″ by Chris Powell.

Prepare your ignore list
Now its time to prepare for the repository. First, edit your .gitignore file and exclude the doc/ folder which you will be creating in the next step.

Create an orphan branch
Create a new independent branch with the git checkout option --orphan. The option is available since Git 1.7.2. Initially, you will have to remove the files that have been created in the working directory, but right after the branch is independent.
Now you can create a doc/ folder and create documentation files. In the end you can commit them to the repository as usual.

git checkout --orphan documentation
git rm -rf .
mkdir doc
cd doc
// Do work.
// git add your files to the doc/ folder
git commit -m "Added documentation files."

Checkout the master branch
To checkout the master branch while still being able to list the documentation files do the following.

git checkout master && git merge --no-commit documentation
git reset master

The files added to the documentation branch earlier will appear in the working directory visible to the master branch. Thanks to the .gitgnore file they will not be listed as untracked files.

The initial discussion on an unrelated branch can be found on stackoverflow.com. Thanks to hillu, tcovo and phord for their input!