Removing Autobahn from Mac

A quick tip for anyone who upgraded to Mac OS 10.7 (Lion) and somehow has “Autobahn” installed. To remove Autobahn (shown as “com.swarmcast.autobahn” in your console log) and stop the constant popups asking you to install a Java runtime:

  1. Click your user name in the sidebar of a Finder window.
  2. Click “Go” in the top menu while, then press “option” on your keyboard to make “Library” visible. Click “Library”. Verify that you are in username/Library and not harddrivename/Library.
  3. Click the “Application Support” folder.
  4. Click the “Swarmcast” folder.
  5. Double-click the uninstall script.
  6. Popups should stop.

To summarize: the offending program is found in

username/Library/Application Support/Swarmcast

There should be an uninstall script in that folder. Run it to uninstall Autobahn.

 
More information on the now hidden Library –
Dots & Thoughts – OS X Lion : the hidden Library

If you’re getting the CS5ServiceManager java runtime notice see this post –
Dots & Thoughts – Speed up Adobe CS5 apps launch

MAMP and PEAR

I finally added some PEAR packages to my MAMP Pro installation. Theoretically you should be able to use the PEAR installer that comes with MAMP. I’ve used the PEAR installer on other servers, but couldn’t get it to work on the local development environment on my Mac. I’ve found a few posts from MAMP users who recommend using the installer, but if any of those users got it to work on their own systems, they didn’t share the details of how they did it.

Success came by following a manual process similar to that copied from the Neo Geek article below, Setting up MAMP, PEAR, and Headress:

PEAR Installation

  1. After locating the framework you want on pear.php.net, download the latest version (or the version you need for testing) from the "Download" tab on that framework's main page.
  2. Unzip the downloaded file.
  3. Open the folder that was extracted to find another similarly named folder and a file named package.xml.
  4. Copy just the folder to Applications/MAMP/bin/php5/lib/php/. (I copied just the contents of that folder to the HTML folder in my example below.)

Notes on Step 4: 1) If you are using MAMP Pro, you still install your pear packages in the MAMP path shown. 2) There is a PEAR folder in Applications/MAMP/bin/php5/lib/php/ PEAR packages you add manually go in Applications/MAMP/bin/php5/lib/php/ not in Applications/MAMP/bin/php5/lib/php/PEAR/

I didn’t want to change include statements in the scripts I was testing. Instead I created a folder in Applications/MAMP/bin/php5/lib/php/ for the top level package name, HTML in this case, and copied the files in the extracted package folder into the HTML folder. So for HTML_Common there is a file named Common.php in my Applications/MAMP/bin/php5/lib/php/HTML/ folder. If this path structure doesn’t work for you, refer to the error messages PHP is generating to help you figure out where to locate packages.

CSS “display: inline-block” in IE7

The CSS property “display: inline-block” only works in IE7 when it is applied to selectors that are displayed natively inline. For example, if you have an <h tag that needs to display as an inline-block you need to wrap the text with a span. This should be done with the span inside the h tag because valid XHTML doesn’t allow native block elements to reside inside native inline elements; e.g.

<h1><span class=”ie-block”>My Inline Headline</span></h1>

This is all over the Internet in various forms. There are many more complicated examples of using inline-blocks in IE. Just thought I’d post this simple note about it.

Printing crashes Internet Explorer 7

Every web developer knows that Internet Explorer does not comply with published web standards. IE7 is much better than IE6, but we still spend many hours restructuring code and/or writing specific stylesheets so that our web pages display acceptably on Microsoft’s browsers. I recently became aware of another problem with Internet Explorer; attempting to print some web pages can cause Internet Explorer to crash. If certain plug-ins, like Google toolbar are installed, “crashing” may be replaced by erratic behavior like redirection to the browser’s home page.

I learned about the crashing problem when one of my clients reported that trying to print a page on their staging site caused the browser’s home page to load; in this case Google. I ran the HTML and CSS validators on W3C with no errors or warnings, but the client was still redirected when they tried to print, and IE7 crashed on my test box when I tried to print. So basically correct, valid, accessible HTML/CSS caused a fatal error in Internet Explorer. The Google toolbar was catching and redirecting the error on my client’s computer which disguised it and made it more difficult to track down.

After much searching, I found a knowledge base article on Adobe’s site which describes this occuring with IE6. The browser “renders the page correctly but crashes when parsing code for the printer”. I believe IE7 suffers from a similar problem, although IE7 may crash on different pages than IE6. Adobe’s fix, adding media=”screen” to the css link tags, allowed the page to print from IE7 without crashing, but, as expected, all page formatting is lost.

Example of stylesheet link:

    <link rel="stylesheet" href="example.css" type="text/css"media="screen">

 
That is ok, even preferable, for most users. Even better would be a specific stylesheet to print a simplified version of the page with extraneous data such as background images stripped out. In fact, I have some clients who would purposely break printing of their site just to save trees, but this particular client wanted their web pages to print as closely as possible to the way they are displayed in the browser. My solution was to provide dynamic PDF generation for printing. I’ll write more details about that in another post.