Logitech MX Revolution configuration

August 24, 2009 at 10:44 PM | categories: Linux | View Comments


The other day @shuckins mentioned that

I'm finding the MX Revolution quite awesome except that I really miss my scroll wheel click button.

This was an issue that I had when I started using this mouse as well. The key feature of the mouse being that a middle click will switch the scroll wheel from smooth movement to discrete (chunky?) movement and back again. This is actually very cool to use once you've gotten accustomed to having the option of scrolling down a page with fine control of speed/distance and then click once to then flick back up to the top of a page.

What I did to make my life easier with this mouse was setup the thumb scroll wheel to act as my middle click that I was accustomed to having. I accomplished this via the btnx-config program as available from the btnx website.

ThumbPress

Configuration for thumb wheel press/click

Once I found out how easy it was to get the middle click from the thumb wheel I decided to make the thumb up/down also have some functionality. If you use firefox and/or gnome terminal I find the most useful thing to map was thumb up to shift pageup and thumb down to shift pagedown.

ThumbDown

Configuration for thumb wheel down

With these set this way I can switch tabs on both firefox and gnome-terminal w/o moving back to the keyboard. The other neat thing I found (when I actually noticed) was that this mapping holds even when using synergy to control two (or more) machines.

The mouse works great, and I haven't in recent memory ever like a mouse as much as I have this one. Couple the nice manufacturing with the ease of button configuration provided by the great programmers of btnx and I think its the perfect mouse for a programmer. Especially one who doesn't like to have to constantly switch between using the mouse and keyboard.







Getting stfl working on fedora 11 x64

July 30, 2009 at 11:14 AM | categories: Linux | View Comments


Newbeuter is my preferred way to browse RSS feeds. Its a great CLI app that is 'Mutt Of Feed Readers', and being a user of mutt I love this app for being so similar. I wanted to use the newest version of newbeuter, because recently I have been on a kick to get all of my apps: screen, vim, mutt, and now newsbuter; setup with 256 colours.

I read on the development blog that the newest version in the git repo was able to use 256 colours, so I immediately cloned the repo and started the install process. I was stopped immediately at the config.sh. It wanted the stfl libraries and wasn't able to find them, and neither could yum.

Looking into the config.sh I saw that it was querying pkg-config for the flags to use on compilation to see if the library was present. It wasn't, and so I also read further on the notes for the git repo version, and saw the bit about using the latest svn copy of stfl. So I checked that out, made it and installed it onto my machine. But this didn't get me any further into making newsbueter, because pkg-config was still unable to find libstfl.

So I decided to try and figure out what the issue was with stfl and pkg-config. First thing I saw was that the stfl.pc file that pkg-config uses to make its responses was in the wrong place for my system. It was in /usr/local/lib/pkgconfig, instead of with the other libraries on my system in /usr/lib64/pkgconfig. This resolved the issue of pkg-config not knowing where the pc file for stfl was, and pkg-config was now returning actual data about libstfl. A recompilation of newsbeuter did show that there was still a problem. I now received: error while loading shared libraries: libstfl.so.0: cannot open shared object file: No such file or directory.

I did another updatedb, and ran a locate for all stfl files, and found that the make install for stfl was putting the libs in a strange place as well. I then updated both the Makefile.cfg and the stfl.so.in to reflect the locations of other libs:

Makefile.cfg changed lines

export libdir ?= lib64
export prefix ?= usr
export DESTDIR ?= /

stfl.pc.in changes lines

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include

This got me pretty far I think, because now the system looked like the other libraries. The stfl.pc lines were taken almost verbatim from the sqlite3.pc file in fact. I was still getting the shared library issue though, and after not thinking about the problem for a bit I realized that the stfl makefile had made libstfl.so.0.21 and the error message was not able to find libstfl.so.0, so I too the logical leap and made a symlink named libstfl.so.0 that pointed to libstfl.so.0.21 in the /usr/lib64/ directory. After making sure that this worked, I made a change to the makefile for stfl, and added another line to make a second symlink, that ended in 0:

Makefile

ln -fs libstfl.so.$(VERSION) $(DESTDIR)$(prefix)/$(libdir)/libstfl.so.0

I do admit that there may be a better way to do this, and some of it may be done with command line config or make flags. I don't know them, and was able to successfully build with these changes.







« Previous Page -- Next Page »