sushi-k.com

A useful wiki with speed tests of various USB memory sticks (jump drives):

http://usbmem.heriet.info/

Every once in a while the scroll ball on my Mighty Mouse stops working.  According to google, this happens to approximately everyone who owns one.  Cleaning with a little bit of cotton and alcohol worked for a while, but recently I lost the ability to scroll down.  Doh.

After trying all the usual methods I found this wonderful description of flossing the scroll ball with tape.  Worked like a charm!

I was making things too hard again.  The mac control panel lets you swap modifier keys on a per-keyboard basis.  That’s enough to solve the problem of the Apple and Option keys being backwards on a USB windows keyboard when used with a mac.  (I had given up on using the control panel stuff before because it can’t do arbitrary key remapping.)

Let’s keep this short:  hooray for Mobility Modder!  It seems that Apple only distributes quite old ATI drivers with their Boot Camp updates, and this was crashing at least one OGL program I was developing.  Like most other notebook manufacturers, Apple also prohibits ATI from allowing their “reference drivers” (read: “most up-to-date/fast/stable drivers”) to be installed on Apple hardware.  That’s where mobility modder comes in, providing an app to modify the latest ATI driver distribution to run on most notebooks.

So my code is working again.. yay!  Now if only I could get back the 8 hours or so I spent debugging Apple’s driver update policies.

BTW, I wonder if this would also fix a crash I was having with FXComposer…

It’s only taken me 4 hours, but I’ve finally got my MacBook Pro’s japanese keyboard acting like a … japanese keyboard.  At some point in the recent past, Vista decided that the keyboard layout was really US, so colons, @ marks, and lots of other keys were mixed up.  I still have no idea what caused it, but this registry hack has restored order to the world, for now.  I want half my day back.

It took forever, but I’ve finally managed to do it.  The installer would start up saying “preparing to install” or the like, then disappear and nothing ever happened.  Finally a thread on macrumors tipped me off that it was a localization issue.  I have Japanese Vista Ultimate running with an english language pack.  Switching everything to Japanese and then rebooting solved the problem.  Note that Vista tells you to log off, but you actually need to reboot.  What is it with Windows and rebooting?!

I was reading the handy Apple OpenGL Programming Guide for Mac OS X when I found a joke right in the middle of the “Using Extensions to Optimize” section, of all places!

Note that OpenGL does not use DMA for a power-of-two texture target (GL_TEXTURE_2D). So, unlike the rectangular texture, the power-of-two texture will incur one additional copy and performance won’t be quite as fast. The performance typically isn’t an issue because games, which are the applications most likely to use power-of-two textures, load textures at the start of a game or level and don’t upload textures in real time as often as applications that use rectangular textures, which usually play video or display images.

What a bunch of pranksters!

Wait a sec, you guys are serious?!

…

If this were an episode of Star Trek, now would be a “set phasers to kill” moment.

After downloading the plugin ages ago, I finally got around to installing the incremental search input manager which adds emacs-style incremental search to cocoa text widgets on OS X. I had problems getting it to work on leopard until I discovered some Leopard-specific issues with input managers. What I ended up doing was:

1. build from source using XCode
2. sudo cp -pR IncrementalSearchInputManager /Library/InputManagers
3. sudo chmod -R go-w /Library/InputManagers
4. sudo chown -R root:admin /Library/InputManagers
5. sudo chmod a-x /Library/InputManagers/IncrementalSearchInputManager/IncrementalSearchInputManager.bundle/Contents/MacOS/IncrementalSearchInputManage

Of course while writing this post I discovered that there’s a universal binary available on the author’s site, so maybe I didn’t need to rebuild at all. In fact, I was trying to use a PPC binary on an intel machine the whole time, so maybe the instructions in the readme are, in fact, ok. The whole situation is confusing though, as the sourceforge wiki seems not to be updated and most of the pages linked to on the web are MIA.

Anyway, it can be done, and life is happy.

Update: or maybe not.  I can’t get it to work in Mail.app or Xcode.  Doh.

This is how I set up a FLTK project under XCode 3.0, which is current as of this writing. I assume that fltk is installed under /usr/local; if not then modify appropriately. This will produce an OS X application, meaning something you can double-click in Finder to run. Note that the link line below forces the project to be statically linked against the fltk libraries, instead of a dynamic link. The reason I do it this way instead of dragging the libraries into the project is because that part of XCode is horribly broken — a library reference in the GUI translates to the gcc command line option ‘-llibname‘ which will search for the library and prefer dynamic libraries.

Note also that the following settings will produce an app built with the default system SDK, so on Leopard it will build against 10.5 and not work on Tiger systems. To build a universal binary you need to make sure fltk was built against 10.4u and set the Base SDK Path appropriately.

1. create a c++ command line tool project
2. delete the command line program target
3. add a new target of type Carbon C++ Application
4. under the target “Build” preferences (command-i):
   • add the following to Other Linker Flags:
     -framework CoreServices -framework ApplicationServices -framework IOKit -framework AGL -framework OpenGL /usr/local/lib/libz.a /usr/local/lib/libfltk.a /usr/local/lib/libfltk_images.a /usr/local/lib/libfltk_jpeg.a /usr/local/lib/libfltk_gl.a /usr/local/lib/libfltk_png.a
   • add /usr/local/include to Header Search Paths
   • optionally add a precompiled header to be included everywhere (search for prefix)

5. drag sources into the Source folder (or something else you create). be careful with the copy files into group option, it’s enabled by default.
6. delete the automatically generated main.cpp
7. Build and you’re done!

After upgrading to Leopard I started getting the error message “Could not create LocalIsochPortInterface”. Eventually I found that building libdc1394 against the universal SDK did the trick, like this:

./configure CFLAGS=-isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -arch i386

Clearly something has changed in 10.5.