I still haven’t found a way to copy text out of the document, but I have found a couple of ways to read Pages documents. You can see a preview of the document when you click on the Quick Look icon in the Finder window (the little eyeball icon), but it disappears if you go to any other program. But I often want to type up sections that I read from the document.

For a while, what I would do to quickly work around this is right-click on the document (yes, I use a mighty mouse, I do have a right-click), and click “Show Package Contents”. There’s a jpeg thumbnail in the QuickLook folder that is barely readable, but readable no less. You can open this in Preview or Photoshop and transcribe content from there.

Tonight, though, I found an even better way. The Quick Look that shows up in Finder is a lot better quality than the jpeg thumbnail. To capture this, I clicked on Quick Look to pull up the document. Then, I did a screen capture of the Quick Look using Leopard’s built in Command-Shift-4 screen capture.

Still not as good as having text to copy and paste, but it’ll do for now….

One plugin that I found particularly useful for this client was Event Calendar 3. On her previous website, the client had a list of upcoming events and wished to have a similar setup on all pages of her blog. There are several calendar plugins available for WP, and I chose this one for a couple of reasons (and due to some Apache permission problems on her host with some of the other calendar plugins). First of all, it’s really easy to use and customize. I was able to set up the sidebar to display just the dates and titles of the events. Second, the events are all posts, so there’s no limitation on what additional information can be posted with the event.

Where I ran into problems with it is that WP treats the posts like any other blog entry. When I click on the category “Upcoming Events” it displays all the posts and the date they were posted, not the date the event is happening. Working with the default WP theme, my work around involved editing styles.css and archive.php:

First, I put the date as the first line in the post for all “Upcoming Events” posts. After that, there were two dates displayed, the first line was the post date and the second line was the event date. To format the second date to match the first, I grabbed the first paragraph of my post (in category “Upcoming Events”) using the first-child pseudo-class:

.category-upcoming-events .entry p:first-child{
color:#666;
}

I didn’t want to get rid of the post date for all categories, so my next step was to change the way archive.php displayed posts with the category “Upcoming Events.” In the WP Loop (the section that spits out all the posts), I edited the following section:

<h3 id="post-<?php the_ID(); ?>"><a title="Permanent Link to <?php the_title_attribute(); ?>" rel="bookmark" href="<?php the_permalink() ?>"></a></h3>
<small></small>

The part between the <small> tags is the part that displays the time when the post was created. WP has a handy built in boolean function in_category() that returns true if the current post has the category indicated inside the parentheses. A trick I use all the time to save on code and headaches in PHP is using an IF statement and exiting PHP before my ‘if true’ statement so as to avoid having to use echo or print, and then going back into PHP and closing the if statement after the HTML, like so:

if(foo == bar){
?>

Hello World!

}
?>

Using this style in archive.php, I check the current post to see if it isn’t in the category “Upcoming Events,” and provided it’s not, I let php go ahead and echo the time the post was created. Otherwise, it just continues without echoing the time. Like so:

<h3 id="post-<?php the_ID(); ?>"><a title="Permanent Link to <?php the_title_attribute(); ?>" rel="bookmark" href="<?php the_permalink() ?>"></a></h3>
<small></small>

This is all great and dandy, but my next project in this is to display the events in chronological order, in case a last minute event is added to the schedule. Stay tuned.

It took quite a bit of looking around and testing different tabbed interfaces, I settled on Coda-Slider by Niall Doherty. The Javascript uses the jQuery library, so I was excited to use it as an opportunity to play around with it (having mainly relied on the MooTools library in the past).

You can see the demo here.

Things I liked about Coda-Slider (and why I chose it over other Javascript tabs):

1. It degrades gracefully.
2. It loads quickly. Some of the other tabs I looked at degraded gracefully by only loading a style sheet if Javascript was enabled. Coda-Slider uses Javascript to alter the classes/ids of objects. The benefit that I noticed is I don’t get the appear-then-change jumpiness that degradable Javascript is prone to. This works because the style sheet is already loaded and cached in the browser and all that happens at run-time is the class/id changes, rather than loading another external stylesheet.
3. It’s not too bloated (though I trimmed it down quite a bit).
4. It allows for directly linking to a specific tab by changing the hash in the URL.

One thing that Coda-Slider didn’t do that I wanted it to do was re-size the window depending on the size of the content- which was a great opportunity for me to get down and dirty with jQuery.

First, I created an array to hold the different panel heights. I used jQuery to find all of the divs with id=”panel” (all those that contained my content), and for each of them, determine the height and push that height into my array:

// Create array of panel heights, set from CSS...
var panelHeights = [];
container.find("div.panel").each(function(){ panelHeights.push($(this).height())});

Then I had to make sure that the height was automatically set to the first tab that was open. Coda-Slider has code in it to determine which panel is showing, so I used that to find the right height in my array (remembering of course that Javascript arrays start with 0, so I subtracted 1 from the current panel number):

// Set initial height
container.css("height" , panelHeights[cPanel - 1]);

And last, I animated the change in height so it would match the sliding in of the new content:

jQuery(this).parent().parent().parent().parent().find("div.stripViewer").animate({ height: curHeight}, settings.easeTime, settings.easeFunc);

You can take a look at all the sourcecode here: http://zbrustudios.com/demo/adjustable-height-tabs/

Another note: Coda-Slider was equipped with a bunch of code I didn’t need, so I stripped that out. Also, I changed the code to work with jQuery Easing Plugin 1.3 without the compatibility script that Coda-Slider needed.

All in all, I was very impressed with the jQuery library. It’s really easy to use and understand. It may be that I’m far wiser now than when I first learned to use MooTools, but syntax of jQuery seems easier to read.

being one to minimize clutter on my computer, i’m pretty excited about Overflow, a nice little addition to the OSX dock. it’s like having a spare room on my dock for all those in-between programs and folders that i don’t visit as often as Photoshop or Firefox, but i don’t want to search for amongst the Calculators and iDVDs of the applications folder. it’s going to be a great way for me to have the convenience of the dock and the Finder sidebar without cluttering either of them. ah, godliness.

another sweet productivity tool that popped up in the last nanoMission was Fresh. this is another great productivity boost: it keeps track of files i’ve used recently in any application, and has a cooler section where i can put files i know i’ll be coming back to soon. i’ve just started using it, but i know it’s going to fit into my design workflow perfectly and keep me from constantly having to retrace my steps through Finder to get to the depths of a client folder.

so a hearty thanks to the folks at Stunt Software for Overflow and Ironic Software for Fresh, and the good, good folks at MacHeist for keeping me excited about all things Apple.

previously, i was using MacJournal for updating this blog, and i really enjoyed using it. it’s really easy to use, i can keep all sort of notes in it and organize them well, and it’s so easy to publish to WordPress sites. but it’s not entirely necessary. and i did just drop a bunch of money.

i also had a bunch of fun software (like iStopMotion – a great program for doing just what the title says), but i’m hesitant to clog up my new machine. on the other hand, it’s got way more space and processing power, so maybe it’s no big deal.

anyway, i feel like i’m rambling. here’s something of more substance:

having just started working on such a huge screen, i was reminded this week of the importance of checking work on different browsers and screens. i just started work with another client where i was handed a site that was mostly completed, but in pieces. i went through and put it together and tweaked the css so that it actually worked – or so i thought.

i was using a standard centered container, with a footer attached to the bottom. i do this with the following css:

html, body{
height:100%;
}

* html #container {    /* for browsers that don't recognize min-height */
height:100%;
}

#container{
min-height:100%;
margin: 0 auto;
width:980px;
position:relative;
}

#footer{
height:30px;
width:980px;
position:absolute;
bottom:0px;
}

this normally does the trick just fine with html laid out like this:

<div id="container">
<div id="footer"></div>
</div>

and indeed, once i had it laid out that way, it looked great: centered content, footer attached to the bottom when the content didn’t fill the container… at least on my new large screen.

i should mention the first time i realized i had to do something to attach the footer to the bottom of my screen was when i looked at a project on a larger monitor and realized it wasn’t: on my smaller screen, it wasn’t very often that the content didn’t stretch to the bottom of the browser, so i normally didn’t notice.

turns out this goes both ways. when i emailed the site to the client, i was told that there was a problem with the content disappearing behind the footer. and it was. when i decreased the size of my browser window, everything inside the content section slid behind the footer. the problem was that the previous designer had needlessly put “float:left” on everything inside the container (except the footer), so it was floating behind the footer. but that’s not really the point.

the point is, having only viewed it on a large screen, i hadn’t even noticed something that would have been glaringly obvious on a smaller screen. so it goes both ways, and it’s still very important for me to check my work on multiple screens.

UPDATE #2: tried out v.0.4.2, and i’m having the old stacking issue, so i went back to v0.4 with my additions listed below.

UPDATE: v.0.4.2 is out now, with an even better fix than i came up with!

hooray! a new version of mooTicker! i’ve been using mooTicker for a while now on sites to do a fade-in/fade-out of quotes. it works by setting the display value of items in a list to display: none, then sequentially changing toggling them between display:block and display:none, with a nice little opacity fade in/out on either end. i’ve had some difficulty in the past with the code not changing to display:none quickly enough, with the result being that my list items slowly stacking down the page on top of my other content.
i’ve always recoded around the problem in the past, but in addition to adding a ‘group by’ option, huug helmink has updated the code to be a little more elegant. but i still had to do some tweaking (posted on google code).
what i found was the list item styles were being changed to display:none before the opacity change started, resulting in an abrupt disappearance rather than a gentle fade out.
here’s my workaround (or see it on google code):

i pulled the display:none code out of the fadeMessage function into its own hideMessage function:

fadeMessage: function() {
  this.group.each(function(item) {
    item.tween('opacity',0);
  }.bind(this));
},

hideMessage: function() {
  this.group.each(function(item) {
    item.setStyle('display','none');
  }.bind(this));
},

Then I added the following line to the showMessage function at the very end (showing the fadeMessage delay for context below):

this.fadeMessage.delay(this.interval-2000,this);
this.hideMessage.delay(this.interval-1000,this);

and it’s working like a pro for me now.

today i’ve been checking half-heartedly. i’d seen the same page of refurbished macs so often that i think i was going a little nuts. this is how nuts:

i just bought an iMac!!!

after all that, i went back to my original thoughts about buying a better machine. i figure if i clean up my iBook it’ll last me another few years of intermittent traveling, and the rest of the time i’ll have my beautiful 3.06GHz processor, NVIDIA GeForce 8800 GS with 512MB of GDDR3 memory and 24″ screen iMac.

i’m a firm believer in signs, and i think i had to go through all this to get the computer i really want. originally, i was going to get the 2.66GHz 20″ iMac, but after thinking about paying somewhere in the neighborhood of $2,200 for a MacBook Pro, my budget for the iMac jumped. and i’m feeling really good about spending more, too. desktops stick around longer and tend to go obsolete rather than die (unlike laptops, in my experience), so it’s worth getting a machine that will last a little longer.

the one thing that made me think real hard about it is the difference in graphics cards between the 3.06GHz iMac and the 2.53GHz MacBook Pro, being the NVIDIA 8800 GS or 9600M GT, respectively. Thanks to a discussion on just this subject on the apple discussions site and ultimately the comparison done at barefeats.com.

hooray! i’ve got a new machine on the way!

the backstory: i’ve been ready for a new mac for about six months now. i’m on a G4 iBook, and while it’s still performing its duties, it’s moving at a pace that’s encouraging me to take far too many trips to the kitchen. at first i was thinking about getting an iMac, which would be my first apple desktop. i figured since i’m mostly working at a desk now, a desktop would be fit quite nicely. plus the huge display. plus the lower cost for more power.

so i was waiting for an upgrade to the iMacs. then it came. then i decided to wait until i could get it refurbished from the apple website. then when it was finally available refurbished, i was traveling, and i realized that although it would be grand to have such a wonderful desktop, i travel a bit and i really couldn’t do without a laptop.

so then i was back onto laptops. the buyer’s guide at macrumors hinted at an upgrade to the macbooks, so i waited. then the new aluminum macbooks came out, and i waited for them to show up refurbished. a couple weeks back, there they were, and i decided to wait yet again because i realized i could save about $175 in sales tax if i waited until the next time i went to oregon (which will be the second week in february).

have you noticed all the waiting? i sure have.

so tonight i was filing my b&o tax forms for washington state, which is the first time i’ve done such a thing. and what should find? turns out my sneaky little no-sales-tax-in-oregon trick isn’t something washington puts up with, and in order to claim a tax deduction on my computer i have to pay a use tax equivalent to sales tax if i buy it somewhere outside of washington!

all this waiting. so much time that me and my new mac have spent pining for each other. only to find out it’s needless time apart!

quick as a flash i went to the refurbished section of the apple store. and they’re out. no refurbished aluminum macbook pros. sadness, frustration, ridiculousness: all things i’ve been feeling in waves tonight.

i decided to check one more time before i went to bed, and then i saw it: the infamous yellow post-it informing me that the store is being updated!

and so i’m here. waiting. again.

ridiculous.

i’d really like to take some time to update what i’ve been working on, and the little tricks that always seem to sprinkle out of big projects, but i think it will have to wait until i’m sipping silk nog and surrounded by bows.