Categories
fixing your desktop

Fix Eclipse’s fonts on OS X

Eclipse current version (3.7?) randomly chooses some of the fonts from the System Font settings – this strikes me as rather stupid: you are only “allowed” to customize 90% of the fonts.

Since OS X (10.6.7) still can’t render fonts correctly, when Eclipse grabs the system fonts, they’re often “wrong”.

In Eclipse, you can choose most of your fonts by hand, and choose the font size etc. Combining this with the fixes (1, 1) that force Apple to stop “blurring” every font, you can almost get a useable Eclipse on OS X.

Almost.

Because of the stupid design mistake I mentioned above, the Package Explorer font in Eclipse is “non-configurable”. You want to change it? Give up. Eclipse won’t allow you.

Options

If you’ve used my other fixes for OS X, you’ll have fonts rendering nicely – as long as they don’t get too small.

Eclipse is hard-coded to make the Package Explorer use a stupidly small font. You cannot fix this. It’s a bug in Eclipse that’s been around for a long long time.

On most platforms, this is fine – your system fonts can be resized.

Except on OS X, where the OS has such terrible font-support.

Because of these two bugs (OS X has bad fonts … Eclipse is hard-coded to use small fonts), if you “fix” your OS X fonts to work for most apps, they’ll be broken in Eclipse.

Disabling system-fonts in OS X

The nearest I’ve found is that you can force Eclipse to ignore the *some* of the system fonts, by editing this file:

[eclipse install folder]/configuration/config.ini

and adding the lines:

# Use system small fonts (Mac OS X only)
org.eclipse.swt.internal.carbon.smallFonts=false

Fixing the Log Output window

This one is relatively easy when you spot it: the ADT plugin ignores all the existing fonts in Eclipse, and sets it’s own unique font, for literally one panel only (the coloured log / console pane).

The official name for that pane is LogCat (incidentally, by default, Eclipse hides this pane – even though you absolutely need it while working with Android – you need to go to the Window/Show Perspectives menu and manually add it).

In the main settings for Eclipse … Android, there’s a section LogCat, where you can set the font. This doesn’t actually work – it’s got a bug, and will crash itself – but if you ignore the crash, and restart Eclipse, your changes will be honoured.

What would really be nice

…is if Eclipse added literally one option to their fonts dialog: an option to manually choose the “missing” hardcoded font. Then all would work great.

…or (much more unlikely), if Apple would fix their entire font-rendering system. Over the years, they’ve fiddled with it a few times. They *know* that it’s “technically correct for print-designers, but completely incorrect for many normal users” they *know* that users find it impossible to work with – but their solution so far is to keep removing features and options, and forcing all users to get a mediocre (or plain bad) experience. Hubris, I think.

Categories
android fixing your desktop programming

August 2011: Google’s install process for Android is still terrible

Following my own install-guide from Jan 2011 (because Google didn’t provide one at the time)…

  1. Google still doesn’t provide an install guide
  2. Eclipse is a *little* clearer on what to download – but only slightly
  3. Eclipse.app on Mac OS X is *still* broken
  4. ADT is still “hidden” by Google for no good reason (my install guide still works)
  5. Google still blocks you from downloading any “Android OS platform” (this is a core part of the SDK that is *not* included in the SDK – you need it to make Android apps)

(also, in passing, I updated the instructions to be a lot clearer / a bit more idiot-proof. I just used them to do a fresh install, and it went smoothly – with fewer problems than trying to use Google’s auto-installer)

EDIT: On the plus side:

  1. My install guide spared me waiting for an extra 0.5Gb of Android OS platforms to download (I was able to copy/paste them on the hard-drive, no extra install work needed. Just don’t use the installer!)
  2. ADT v 12 is noticeably more stable and better-integrated with the Android emulator – auto-starting smoothly where previous versions needed you to lead them through baby steps on first-run

Which means the key problem from a year ago still holds today:

Google is still effectively blocking you from using Source Control on Android projects

And they wonder why people still prefer the pain of working with Apple…