1. Backup your original jEdit.app application bundle (I called mine jEdit.orig.app).
2. Open up jEdit.app (right click and do “Show Package Contents”). Navigate to “Contents” > “Resources” > “Java” and copy the jedit.jar file to your Desktop.
3. Open up /Developer/Applications/Utilities/Jar Bundler.app.
4. Next to the text field that says “Main Class” click the “Choose…” button and navigate to the jedit.jar copy that you just made on the Desktop.
   
5. Make sure “Use Macintosh Menu Bar” is checked and press the “Create Application Button” at the bottom. Call the application “myJedit” or something else that distinguishes it from the original.
6. Open up your new jEdit application bundle (“myJedit.app”) using “Show Package Contents” and navigate to Contents/Mac OS. Inside here you should see a file called “JavaApplicationStub.”
7. Copy “JavaApplicationStub” from your new jEdit bundle (“myJedit”) to the Contents/Mac OS directory in your original jEdit.app bundle.
8. Inside the original Contents/Mac OS directory you should see an alias called “jedit.” Rename this “jedit.bad” or something similar.
9. Go one level up in the jEdit.app bundle to “Contents” and open up the “Info.plist” file. This open up using the Property List Editor (it lives in /Developer/Applications/Utilities).
   
10. Expand the tree and change the ‘CFBundleExecutable’ string from ‘jedit’ to ‘JavaApplicationLauncher’.

That’s it! Close up the jEdit.app bundle and double click on it. jEdit should start normally as it used to, complete with the Mac Menu bar. Additionally, if you’ve installed the jedit shell script for launching jEdit from the terminal that should still work as well.

It’s not the prettiest solution but it keeps me going for now until a better fix is released.

UPDATE:
Someone in the Apple forums pointed out that simply copying the destination of the jEdit.app/Contents/MacOS/jedit symlink, which points to

/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub

back into jEdit.app/Contents/MacOS/jedit (replacing the symlink with a copy) also makes the jEdit application bundle work again. This method has considerably fewer steps than mine.

Apparently this file is functionally the same as the one generated by Jar builder. It seems Java developers went for the symlink method specifically to avoid problems created whenever Apple would go and update Java. With this update the symlink doesn’t seem to work again.

On Linux the solution would be to add a -Wl -rpath /usr/local/qwt-5.0.2/lib to my LIBS directive in my projects’s .pro file (in this case the relevant line is in the examples/examples.pri config file). This should add the path to qwt’s dylib to my application’s runtime search path. Unfortunately this doesn’t work in Mac OS X. As it turns out, the library itself has to know its full install path.

So far, the best webpage on this problem I’ve found so far is here. It seems that Mac OS X even comes with its own utility, install_name_tool, to manage libraries’ names if one needs to move them around.

I skipped install_name_tool and opted to simply rebuild Qwt’s dylib so that it knows its install_name. My solution was to modify the LDFLAGS directive in qwt’s src/Makefile so that

-install_name libqwt.5.dylib

Looks like this instead:

-install_name /usr/local/qwt-5.0.2/lib/libqwt.5.dylib

This is not the best solution as I had to modify my Makefile directly instead of the Qt .pro file. After another make and sudo make install to reinstall the dynamic library, oTool -L libqwt.5.dylib confirms that the library’s name contains its own full path:

> otool -L libqwt.5.dylib
libqwt.5.dylib:
/usr/local/qwt-5.0.2/lib/libqwt.5.dylib . . .

More importantly, the Qwt examples all run now and I didn’t have to modify my DYLD_LIBRARY_PATH!

The next step is to modify the .pro file or my qmake.conf so it handles all this install_name magic automatically at compile/install time, but this worked well for now…

{ rank=same ringbuffer inputproc; }  // put two nodes on the same level

and

buffer_a   [label="buffer"]  // give two nodes the same name

buffer_b   [label="buffer"]

Recently a coworker alerted me to the existence of yEd, an awesome free graphing program written in Java. It creates GraphML-format files using a slick, well-designed interface. It has powerful graph-organizing tools and supports SVG symbols as graph nodes. The graphs look great when printed, too.

I’ll try to post more details about its design and how it works in the coming days. For now, visit the main WordRecorder page here.

I don’t know what this is about, but through some hacking and tinkering with the Xcode file I came up with the following messy workaround:

1. Make your Xcode project using qmake -spec macx-xcode if you haven’t already.
2. Open/reload the resulting project in XCode 3. Trying to edit the project properties will yield the above error.
3. Save the Project. This step is necessary as it makes Xcode totally reformat the file making the edit we’re about to do much easier.
4. Open the project’s “project.pbxproj” file in your text editor. It lives inside the “.xcodeproject” folder so you’ll have to do a “Show Package Contents” to see it in the Finder.
5. Find the following comment (“hello_world” will be the name of your own target)

   /* Build configuration list for PBXNativeTarget "hello_world" */

6. Beneath this comment you’ll see the following list of build configurations (the actual IDs will be different):

   isa = XCConfigurationList;
   buildConfigurations = (
   2F9BD7250DBC2F9500BBEE4F /* Debug */,
   2F9BD7260DBC2F9500BBEE4F /* Release */,
   2F9BD7270DBC2F9500BBEE4F /* Default */,
   );

7. Remove the entire line containing the identifier with the name ‘Default’ and save the file. The result will look like this:

   isa = XCConfigurationList;
   buildConfigurations = (
   2F9BD7250DBC2F9500BBEE4F /* Debug */,
   2F9BD7260DBC2F9500BBEE4F /* Release */,
   );

8. Go back to Xcode. It should prompt you to reload the project from disk. Reload it. You should now be able to edit your project’s properties again. Unfortunately you will have to repeat this step whenever you rebuild your project using qmake.

I don’t know why this fix works, but it beats having to recreate our Xcode project by hand, and everything still seems to build without incident after the fix.

I’m not sure if this is Apple or Trolltech’s problem as I can’t remember if this worked in Qt 4.3.3 / Xcode 2. Xcode 3 probably isn’t officially supported by qmake yet, anyway.

A solution comes from the Open Printing Workgroup at the Linux Foundation. By first installing the ESP Ghostscript and Foomatic RIP packages on their website, you can install the hpijs package—too many names, yes. This gives you the hpijs driver for the Deskjet 6800 (and many other printers) with the double-sided option enabled.

I’ve found the hpijs driver isn’t as crisp as the HP drivers (HP Inkjet 3.3.1), and it’s even failed miserably when I’ve tried to print some more complicated PDF files, but otherwise it’s a great way to save paper when printing things like receipts and news articles where quality isn’t my highest priority.

UPDATE: A recent upgrade of the HP Printer Drivers for OS X has fixed this problem. The specific driver is called “HP Inkjet Version 3.3.3”.

While the standard print dialog still has the “Two Sided:” option grayed-out under the Layout tab, a new “Two-sided Printing” tab has appeared in the dropdown list. This one is enabled and actually seems to work properly.