add in ~/.subversion/config
merge-tool-cmd = svndiffwrapper
and create svndiffwraper, somewhere on your path, a shell script which contains:
#!/bin/sh
kdiff3 -m $1 $2 $3 -o $4 1>&2
Subsequent svn merge will offer you the option to (l)aunch the external program do to the merge, which will fire up kdiff3
(Obviously you can use a different tool to kdiff3, but that was the best 3-way graphical merge tool I found in a quick search)
]]>Generating the toolchain on gentoo is pretty easy thanks to crossdev
USE="-*" crossdev -S --target x86_64-pc-linux-gnu
The gentoo cross-compilation guide explains how to cross-compile arbitrary packages
ROOT=/usr/x86_64-pc-linux-gnu/ CBUILD="i686-pc-linux-gnu" CHOST="x86_64-pc-linux-gnu" emerge libpcre
Obviously can't test any of it works, though :S
]]>
jon@clairmont $ mid3v2 10\ 世界はこの手の中に.mp3
IDv2 tag info for 10 世界はこの手の中に.mp3:
TPE1=相川七瀬
APIC= (PNG, 105828 bytes)
TYER=2000
TIT2=世界はこの手の中に
TENC=iTunes v7.7.1
TRCK=10/13
TPOS=1/1
TALB=FOXTROT
TCON=Pop
This all seems to work swimmingly on various players under Linux, but under Windows it's more complex...
- GetWindowText() on the foobar2000 window just returns a load of "?" characters, presumably because they don't exist in the local codepage (unlike accented characters like ö which survive this translation intact). Using GetWindowTextW() to retrieve the title in wide-character form then converting it to UTF-8 seems to work fine.
- Winamp makes an utter hash of returning these characters via the (legacy) IPC_GET_EXTENDED_FILE_INFO interface we are using. Updating to use IPC_GET_EXTENDED_FILE_INFOW fixes this. We also need to use GetWindowTextW() as above for looking at the window title (which we use for stream information)
- The mysterious wmp9.dll seems incapable of returning these correctly from Windows Media Player.... yet another reason to replace this code with something else....
- This all works fine with iTunes, but it doesn't seem possible to actually display the song title correctly in iTunes, since it uses a fixed font (Lucida Grande?) which you can't seem to change and which doesn't have the glyphs. Later: turning on East Asian language support in Windows XP fixes this, presumably as it lets Windows do it's font linking thing to find the glyphs in another font...
So now I know more about this windows wide character nonsense than I ever wanted to. Oh, and I'm now one of the top listeners to Nanase Aikawa on last.fm :-)
]]>
pidgin-musictracker has one additional dependency, libpcre, so you'll need to place a static library of that into win32-dev to link with as well...
]]>Last.fm feed stuff needs some work.... breaks player autodetection at the moment if a last.fm account name is set, perhaps it should look at timestamp and infer off it is more than 5 minutes (configurable?) in the past; the parsing looking for a non-standard hyphen character separating artist and title in the feed data is also questionable.
XMMS2 patch is a bit problematic in that it wants to directly link with xmmsclient library, which gives us a built-time dependency on it. Rejig the autoconfiscation slightly so we can build without it being present, but this still has the problem that binaries which are built with the xmmsclient support have a run-time dependency on it. Should use dlopen/dlsym (as xmms1 support does) to avoid depending on presence of library? (otherwise pidgin can't load it if the library is absent)
pidgin core doesn't provide a way to do this directly, so this involves some kludging, but it's so needed, an action to toggle with no way of knowing if we are currently on or off is just confusing
Winamp player code has some crazy stuff to try to guess the title from the winamp window title when we are playing a stream; sadly this screws up if their is a hypen in the title, which seems to cause lots of people problems; Streams are generally problematic as they probably only have a streamtitle, not all the fields we expect from a mp3....
Not quite able to reliably reproduce the problem case, although I have seen it occasionally: if there is no dcopserver running, sometimes 'dcop' blocks for a while before reporting failure; unfortunately this seems to be the same or longer than our player check interval so we hang pidigin. Othertimes dcop returns immediately with an error, can't quite work out what causing the difference.
Creating a project at google-code and cloning the existing svn repository is surprisingly painless.
Checkin the changes from my patch, and then do some scripting work to automate the release process. Existing makefile omits the windows installer generation stage, so add rules for that (pleased to find that nsis Gentoo package exists, so I can build the windows installer under linux)
This scripting also generates development snapshots
]]>