Tile OS X Terminal window to Finder with AppleScript

I updated my AppleScript that will tile the terminal window nicely below the frontmost finder window.

For some reason setting the Terminal window bounds is very buggy. I resorted to using the deprecated methods {position and size} and have to loop it three times to ensure that it positions correctly.

I tied this to command-; in my app launcher, QuickSilver

tell application "Finder"
 --make new Finder window
 activate
 if not (exists window index 1) then
  make new Finder window
 end if
 set {x1, y1, x2, y2} to bounds of window index 1
end tell

tell application "Terminal"
 activate
 
 if (count of windows) is 0 then
  tell application "Terminal" to activate
  tell application "System Events" to tell process "Terminal" to keystroke "t" using command down
 end if
 
 -- For some reason it can take up to 3 times for Terminal to be properly adjusted
 set L to {1, 2, 3}
 repeat with xxx in L
  set {xx1, yy1, xx2, yy2} to bounds of window index 1
  set position of window index 1 to {x1, y1 + {yy2 - yy1}}
  set size of window index 1 to {x2 - x1, y2 - y1}
 end repeat
 
end tell

OS X Leopard - Improved Terminal (almost perfect)

Sorry iTerm, my long friend. I may be giving you up now that Leopard's terminal has tabs and an over-all improved UI. Terminal starts up fast and is pretty dang stable. One gripe - "Why can't I name the tabs!" Ugh, this seems so obvious a feature. Yeah, you can use AppleScript to set the name of the overall window but that isn't all that helpful when you have multiple tabs open. Come on, this has got to be a two-day feature (one to implement, one to test).

Weird thing is that somewhere in Apple-land there is a small team that is responsible for maintaining Terminal. And they are programmers so you'd think that they'd make the shell as nice as possible and think of these features on their own.

Anyway, bravo for the improvements that did make it in but a small "boo" for my couple of wasted hours trying to figure out how to ActionScript custom tab names. Oh Apple, when you fall short, it really hurts.

OS X Leopard - Incompatibilities

I'm an early-upgrader to Leopard. After a week I'm digging it quite a bit. This is my small list of bitches in a otherwise pretty nice OS. I think a lot of the inconsistencies with the Java-based programs has to do with Apple's new GUI rendering. I don't know much more about it but I'm guessing that it broke (well damaged) a lot of SWT and Swing widgets. Mostly I'm posting these in case somebody else is running into the same issues:

• Intellij - Works but now the UI is unstable. Switching tabs don't always work and a few other creeks and groans. I use this every day so it is a bit painful.


• Popcorn 3 - Bought this last week for my iPhone so I could scale down movies and move them over. This won't even start up. Funny thing is Popcorn 1 still works fine. Roxio has a message on their site that a fix is forthcoming.


• TextMate - Breaking Input Managers was an issue from day one. There is a work-around for the "edit in textmate" bug that works well but it is slightly kludgy.

I don't entirely blame Apple, seems to me if you are a maker of Apple software you'd do some work with the pre-releases to ensure your software still works with the upgrade.

Java 6 on OS X

Hey Apple, please be more vocal with your plans for Java. I love my mac and want to continue using it as my main development machine. I don't doubt good things are happening - just would like more (good) buzz out there. I've seen many Java developers be converted to mac (me included - now I own three macs and an iPhone) and then go on to spread the good word.

13949712720901ForOSX

Groovy XML Markup Builder CDATA block

This is one of those things that turns out to be easy but takes a bit of time to figure out.

Using Groovy's builders there are times where you want more control, like when you want to pump out a CDATA block. This turns out to be quite straight forward:

  out = new StringWriter()
  xml = new groovy.xml.MarkupBuilder(out);
  xml.test_xml {
    normal("Some text in a normal element")
    data('') {
    out.write("<![CDATA[Hello]]>")
    }
  }
  println out  

Basically since we have reference to the writer we can dump out anything directly to it. I'm sure this works with most builders.

The resulting xml block should look like:

  <test_xml>
    <normal>Some text in a normal element</normal>
    <data><![CDATA[Hello]]></data>
  </test_xml>

UPDATE EDIT:

Please note that MarkupBuilder also gives you the special field 'mkp' to do similar actions.

For example:

def out = new StringWriter()
def xml = new groovy.xml.MarkupBuilder(out)

xml.test_xml {
    normal("Some text in a normal element")
    xml.mkp.yieldUnescaped('<data><![CDATA[Hello]]></data>')
}

println out

Also works and probably is more-correct.

OS X Finder iTerm applescript window tiling

If you are an OS X developer no doubt you use iTerm. If you haven't set up your unix environment to synchronize between Finder and OS X you should. There are a number of examples but here is the ones I used since I'm a zsh fan:

iTerm Terminal Customization

Now the other thing I wanted was to have a quick-key combination to display both the front finder and iTerm windows and position them nicely tiled. This way I could work in an IDE but have my bare-bones development windows appear in a snap. Here is my applescript code:

tell application "Finder"
 --make new Finder window
 activate
 if not (exists window index 1) then
  make new Finder window
 end if
 set {x1, y1, x2, y2} to bounds of window index 1
end tell

tell application "iTerm"
 activate
 if not (exists window index 1) then
  set myterm to (make new terminal)
  tell myterm
   launch session "Default Session"
   end tell
 end if

 set {xx1, yy1, xx2, yy2} to bounds of window index 1
 set bounds of window index 1 to {x1, y2, x2, y2 + (yy2 - yy1)}
 activate
end tell

Store the script in your home/Library/Scripts folder and from there you can assign a hot-key.

Why don't I just use PathFinder? Well I own it and used it quite a bit but there are things that just make me angry about it that hopefully they'll fix.

1. It is a resource hog
2. It doesn't allow me to simply type a path into an input box (actually almost all OS X Finder clones have this issue).  OS X developers seem to like the mouse and drilling down.
3. The UI can be quite busy and some things that should be simple (finding files in the current directory or below for example are a pain in the butt.

Anyway, now that I'm doing quite a bit of development on my mac I'm using QuickSilver, Finder, and iTerm with applescript to glue them together. Simple.

What inspired me to dump PathFinder? This great podcast that showed how much hidden value is in the limited basic Finder application and how a little knowledge can make it much better suited to your workflow.

Living with the Finder

Tomat 5.5 Spring 2.0 log4j debugging

Had to dig for this one a bit to get spring framework debug to show up.

Set up logging in Tomcat 5.5

Note: CATALINA_HOME is probably the environment variable pointing to your tomcat installation.
* put log4j and commons-logging in ${CATALINA_HOME}/common/lib
* put a basic log4j.properties file in ${CATALINA_HOME}/common/classes

for example:

log4j.rootLogger=DEBUG, stdout
log4j.logger.org.apache=INFO

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n

Note: I turned org.apache to INFO to ensure I don't get a few miles of digester logging
Note: Of course you could add file appenders if you wish - I'm keeping this minimal

Make sure commons-logging.jar is not in your WEB-INF/lib directory of your web-app. That seemed to be the thing that switched off the availability for Spring debug logging. I'm sure there are other ways to get this going but this worked for me.