Using qmake without a build target

One of the greatest weaknesses of Qt's qmake utility has been its over-reliance on templates. The available templates are standard stuff for Qt projects: app, lib, and subdirs (new with Qt4, I believe). These are all well and good when one is just slapping together a bunch of Qt code, but what about when interfacing with other build systems? A command template would be quite useful.

The follow project file is a workaround. The lib template is used (although app could be used as well) with empty HEADERS and SOURCES variables. The qmake variables that specify which build tools to use are set to a NOP (no-operation) tool such as echo or true. An "extra" target is created for the command to be executed, and set to be a pre-dependency of the main target.

Background: There is a config.py in . that has sip generate all C++ code, as well as the Makefile, in the directory 'sip'. The python module (sip_test.so) is output to the same directory. This project filed is invoked, along with many others, from a subdirs project file in the parent directory.

-----------------------------------------------------
# sip_test.pro
TEMPLATE    = lib
TARGET      = sip_test

# Check that sip exists
unix {
      !system(sip -V > /dev/null) {
              error( "SIP does not exist!" )
   }
}

# sip build command and makefile targets
sip.commands          =    python ./config.py && cd sip && make
QMAKE_EXTRA_TARGETS   +=   sip
PRE_TARGETDEPS        =    sip

# compiler toolchain override
unix {
     # 'true' should exist on Unix and OS X. Win32 folk can
     # use TYPE.EXE or something.
      NOP_TOOL    = true
}

QMAKE_CC        =    $$NOP_TOOL
QMAKE_CXX       =    $$NOP_TOOL
QMAKE_LINK      =    $$NOP_TOOL
QMAKE_LN_SHLIB  =    $$NOP_TOOL

# Copy the .so created by sip.commands to the current directory
QMAKE_POST_LINK        =    cp sip/$${TARGET}.so .
-----------------------------------------------------

With this project file, the standard "qmake && make" command works as expected.

Toshiba R500 Backlight Button

Keep forgetting to u/l this script for toggling the r500 backlight using toshset:

#!/bin/sh

TOSHSET=/usr/local/bin/toshset

STATE=`sudo $TOSHSET -trmode 2>/dev/null | grep -a transreflective | \
cut -f 3 -d ' '`

if [ $STATE = "on" ]
then
NEW_STATE="off"
else
NEW_STATE="on"
fi

sudo $TOSHSET -trmode $NEW_STATE

Xev shows the keycode for the backlight (and the 'i' internet/information/idiot key, so they'll both do the same thing) to be 180, which is already taken by XF86HomePage in Ubuntu. If for some reason this key is undefined (i.e. nothing shows up on `xmodmap -pke | grep '^keycode 180'`), add the following line to ~/.Xmodmap (which might need to be symlinked to ~/.xmodmaprc on non-Ubuntu Linuxes):

keycode 180 = XF86HomePage

In E17, edit the keyboard bindings using Settings-> Settings Panel -> Input -> Key Bindings. For XF86HomePage, select the Launch : Defined Command option, and point it to the above shell script (e.g. in ~/bin).

Note that the script uses sudo to launch toshset, so you will either need to change this to invoke an GUI sudo program like gtksu, or add a line like the following to /etc/sudoers:

$USER ALL=(root) NOPASSWD: /usr/local/bin/toshset

where $USER is your username. Note that this allows any toshset command to be run as root without a password from this user's session, which could be exploited if someone were sufficiently motivated.

Linking static libraries into a shared library

The ability to link static libraries into a shared library -- e.g.

gcc -shared -o libstuff.so lib1.a lib2.a lib3.a
-- disappeared in one of the 3.x series. This broke my tendency to build applications as static libraries, linked into a shared library, linked to by an executable consisting of little more than a main().

Turns out all that was missing was a GNU ld flag to prevent ld from optimizing the unused object code out of the shared library.

The solution is to wrap the .a files in --whole-archive flags, e.g.

gcc -shared -o libstuff.so -Wl,--whole-archive lib1.a lib2.a lib3.a -Wl,--no-whole-archive

Insipid Ibex

Finally upgraded (K)Ubuntu to 8.10. Thanks for breaking my xorg config, guys, by assuming that HAL could actually do a better job that my hand-picked settings. This is easily fixed by uncommenting all of the lines commented out by HAL, but it's amazing that it had to be done at all, since the HAL change made X flat-out stop working. Also, for some reason, ~/.xsession no longer works -- one has to use ~/.xsessionrc instead. Those wacky Ubuntites.

Upgraded E17 shortly afterwards, using the packages at

deb http://greenie.sk/ubuntu intrepid e17

The new version of E has compiz support (which has to almost entirely be disabled for it to run at E17's proper speed) and looks nice. The modules all seem to work, for once.

But it crashes!

The first one came immediately, and was fixed by wiping ~/.e, which contained all of my old config settings. Apparently E17 can't reliably be upgraded with an existing config. Thanks for moving to a binary config file, guys, so that this is actually a far larger problem than it should be. Really, how hard is it to use the binary config only at runtime, and compile from text to binary whenever a config change is made?

Some of the other crashes appear to be from the OpenGeu inclusion of compiz. After removing the calls to emerald and ecomorph from enlightenment_startup.sh, and stripping out the -evil command line option (which, along with -good and -psychotic, did not seem to make things stable), it's become pretty stable, if a little buggy. Dialog boxes occasionally do not disappear when closed, requiring a restart of E17.

Also, some E17 idiocies remain -- things that seemed to be oversights before, but now (having been a pretty stable WM for the past three years) appear to be truly asinine design decisions.

Specifically:

* There is no way to modify the properties of an application (short of adding it to iBar, or modifying the desktop file directly). A dialog exists for this (it's used by ibar and when creating a new application), so it can't be much extra work.

* One cannot cut/copy/paste between E17 widgets and X. This is nice to be able to do when, say, setting an icon file path (since the desktop files for KDE applications do not seem to be handled correctly by E17, and therefore have no icon files). Hope you like typing.

* The binary only config, mentioned above. Really, there is no excuse for this -- the rest of the industry learned that lesson in the 90s. Even Windows allows its abhorred registry to be read from and written to text files.

Aside from that, Ibex works well, and the upgrade was generally painless. The only sticky points were the Xorg conf file (their mistake), E17 (my fault for running it), and the patch I needed to add to get toshset supported by the latest kernel (the maintainer's fault, for not getting it merged after 2 years of reliable performance).

more ffox plugins

These are more for the UI folk:

Colorzilla:Look up a pixel's color value

Unicode lookup/converter : Character lookup utility

MeasureIt : Ruler widget for measuring distance in pixels

Vim links

People either love vi or hate it; if you hate it, sod off and take your parentheses with you.

It's good to have a printout of the vi reference card handy, and a cheat sheet or two saved locally:

Vi Reference Card (PDF)
Graphical Vim Cheat Sheet (GIF)
Vim Cheat Sheet

In support of the "learn a new vim command every day" effort, both Vim Tips and the Vim Cookbook have proved interesting, as has the piping feature.
Speaking of pipes, pv is quite an interesting utility. So is histring, but it doesn't seem to be available (or maintained) except in rpm.

Vim has a ton of plugins worth checking out, including:
FuzzyFinder
OmniComplete
TagList
RenameWithCScope
C Call Tree Explorer
SourceCodeObedience
VimDebug
MiniBufferExplorer
SnippetsEmu
AllFold
Fly
SessionManager
Alternate
RunView
Scratch*
VcsCommand
MultVals
GitCommit
GitDiff
GitFile
Git Branch Info
There is also NERDTree, but its moderate utility does not justify its horrible name.

Most languages have syntax and snippet plugins, such as:
C
Python
Ruby/Rails
Perl
SQL
x86 and x86-64 asm
XML/HTML


Finally, to forestall the inevitable requests, here is a sample .vimrc .

DNS

DNS timeouts have been pretty bad lately; decided to take action and make resolve.conf actually be usable. Of course, it gets overwritten every time DHCP is used to configure an interface, so the name servers have to be added to dhclient.conf .

There are quite a lot of reliable servers to choose from:

OpenDNS
TechFAQ public dns server list
dnsserverlist.org
dnsserverlist.org organized by round trip time

The last two are particularly useful: dnsserverlist.org recommends three DNS servers based on your current IP, and provides an option for sorting their list by round-trip-time.

"Permanent" DNS servers can be added by editing /etc/dhcp3/dhclient.conf and adding 'prepend domain-name-servers' lines:

prepend domain-name-servers 216.224.112.14;
prepend domain-name-servers 67.198.198.213;
prepend domain-name-servers 69.111.95.106 ;
prepend domain-name-servers 208.67.222.222;
prepend domain-name-servers 208.67.220.220;
prepend domain-name-servers 4.2.2.1;
prepend domain-name-servers 4.2.2.2;
prepend domain-name-servers 151.197.0.38;
prepend domain-name-servers 151.202.0.84;
prepend domain-name-servers 151.203.0.84;

Remember to list these in reverse-order: the last server prepended will be the first line in resolv.conf.

The ultimate solution, of course, is to set up a local caching DNS server.