Posts Tagged ‘software’
TaskPaper update
June 29th, 2010 at 11:24 am
A couple of months ago, I complained about TaskPaper’s handling of the user’s password when syncing. The problem was that TaskPaper wouldn’t allow me to paste my Google ID from 1Password into the password field of the dialog box.
I later changed my Google password from a 1Password-generated random string to something I could remember and type in directly.
With the latest version of TaskPaper for iPhone, this bug is fixed. It’s still a hassle that TaskPaper can’t just remember the password itself, but at least there’s now a way to login with credentials stored in 1Password.
(I should mention here that TaskPaper doesn’t require you to log in every time you need to sync. I suspect the login requirement is coming from Google; it’s similar to the way GMail asks for your password every few weeks.)
The future of TaskPaper syncing looks bright. In this blog post Jesse Grosjean describes not just a new note-taking product for iOS (one that might give Simplenote a run for its money), but also an upcoming switchover of all his apps from his bespoke syncing system to syncing via Dropbox. This will be an enormous improvement on both the iPhone and the Mac; we’ll get not just automatic syncing, but also the ability to revert to earlier versions.
I’m kind of surprised how thoroughly TaskPaper has won me over. Its simplicity is a big plus; because it’s just a little more structured than a blank sheet of paper, I can adapt it to many purposes. That its native format is easily converted to Markdown—and, therefore, to HTML—has allowed me to a get great-looking printed task lists to slip into my planner.1
Safari text rendering problem
June 28th, 2010 at 1:15 pm
I’ve been noticing recently that text is sometimes rendering poorly in Safari. At first, I thought it was deteriorating eyesight. Then I thought it was the Retinal display on my iPhone causing me to see pixels on every other screen. but now I’m sure there’s something else going on.
The problem seems most common when I’m reading RSS feeds in Google Reader. Reader uses a smaller font than I like, so I bump up the font size one step with ⌘+. Here’s a snippet of a post1 that rendered poorly earlier today but then rendered well when I returned to it later. The screenshot starts with the bad version and shifts to the good version when you roll your mouse over it.
Do you see the difference? Look in particular at the word “enactment” near the center of the image and at the two links. Once you see the difference in those places, you’ll start seeing it everywhere. Everything is just a little more pixelly in the bad version. It doesn’t seem like much, but it wears on you when reading long passages.
I don’t know what’s going on here. Obviously, the text isn’t always rendered poorly—otherwise, I wouldn’t have been able to get the “good” screenshot—but it happens often enough to be noticeable.
I haven’t noticed this in any other program, just Safari. I can’t say it definitely started with the recent upgrade to Safari 5.0, but that’s my suspicion.
Update 6/29/10
My suspicion was wrong.
I’m pretty sure now the problem was an extra copy of Arial. I went into Font Book and saw the little yellow caution signs by all the Microsoft core fonts, indicating duplicate copies.
I used the Select Duplicated Fonts and Resolve Duplicates commands in the Edit menu, and the fuzzy text problem hasn’t arisen since.
Honestly, I’m sure I’ve removed duplicates of these fonts before; I don’t understand why they came back.
This was obviously a system-level problem and had nothing to do with Safari per se. Safari was the only application I saw it in because it’s the only application that uses Arial or the other MS core fonts.
Update 6/29/10
My belief that my suspicion was wrong…was wrong.
The duplicate fonts are gone, but the crappy looking text is back. Sometimes reloading the page fixes the problem, sometimes it doesn’t. I’m confused and annoyed.
-
From Lawyers Guns and Money. ↩
PCalc 2.1 resolution
June 26th, 2010 at 3:35 pm
James Thomson sent out new betas of PCalc 2.1 last night so those of us with new iPhone 4’s could use it. As I said yesterday, version 2.0.1 was built for the pre-4 display and while it looked great on a 3GS or earlier, it had an interesting mix of sharp text and fuzzy graphics on the Retinal screen. Here’s a screenshot comparison of the middle of the Engineering keyboard layout:
Much nicer, isn’t it?
PCalc 2.0’s resolution mix
June 25th, 2010 at 2:41 pm
A week ago, James Thomson sent out a beta of PCalc 2.1 for iPhone to his testers. It’s the “Retinal” version of PCalc, with the graphics redrawn to take advantage of the higher resolution of the iPhone 4’s screen. At the time, I had no use for the higher-res graphics, but I downloaded and installed it anyway, because there was another improvement I wanted to test.
Yesterday morning, I picked up my iPhone 4 and installed all my apps and music. The PCalc beta wouldn’t install, presumably because it uses the Ad Hoc distribution method and my new phone’s device ID isn’t in the beta app’s provisioning profile. I’m sure James will update the list of his testers’ device IDs soon, but in the meantime I have no calculator.1
After a PCalcless day, I went to the App Store and got the unRetinal 2.0.1 version. I had already bought PCalc back before I was a beta tester, so there was no need to cough up any more money. I fired it up to make sure the settings were right and immediately noticed two things:
- It starts up really fast on an iPhone 4.
- The user interface is a hybrid of (lower-res) graphics and text, which gives it something of a split personality on the new screen.
Here’s a 320×480 view of the screen, what you would see on a 3GS or earlier:
Here’s a section of it in glorious 640×960 resolution:
See how the text—most of it, anyway—is really sharp and the images are kind of fuzzy? It looks like some things you would think are text, like the trig functions, are actually images.
PCalc works fine, of course, it’s just a little funny looking.
The fuzziness will be banished in version 2.1, which is going through the approval process as I type this. I’m looking forward to going back to the future.
Update 6/26/10
I’m back in business with PCalc 2.1. See a screenshot comparison with the new Retinalized keyboard here.
Reports of Dr. Twoot’s death…
June 23rd, 2010 at 4:00 pm
…were premature. OK, there was only one report and it was by me. But the statement stands—Dr. Twoot is alive and may survive the coming OAuthcalypse.
A combination of three things have allowed Dr. Twoot to hang in there:
- The vuvuzela effect. Twitter has been seeing so much traffic for the World Cup, it decided to put off the date of Basic Authentication’s death from June 30 to mid-to-late August.
- That new Twitter SSB I made just isn’t as nice to use as Dr. Twoot, nor is it as compact or customizable. Hence, a new effort by me to figure out OAuth.
- I finally found a spectacularly clear explanation of how a client program should construct OAuth headers. Jaanus’s post, combined with a single access token from Twitter, should allow me to get OAuth working on Dr. Twoot before August.
And if things go wrong? What if OAuth still eludes my grasp? Well, there’s HelTweetica, a Twitter client I just found via a tip from Matthew McVickar1. He noticed an aesthetic similarity between HelTweetica and Dr. Twoot and thought I might be interested. He was right.
Here’s HelTweetica:
And here’s Dr. Twoot at the same window width:
I still prefer Dr. Twoot’s layout because
- The font is bigger. I can’t find a preference or menu choice for font size in HelTweetica.
- The buttons along the right side don’t fill the entire right margin, using the small space more efficiently.
- It’s chronological instead of reverse chronological. I know this is counter to the Twitter Way, but it’s the way I like it.
- Mentions are mixed in with my home timeline. Again, this isn’t how the Twitter website works, but it works for me.
- It has a button for deleting tweets, something I like to do if I notice a speling error2 right after posting.
Despite these preferences, I’d switch to HelTweetica in a heartbeat if I couldn’t use Dr. Twoot.
But I have hope now that it won’t come to that.
-
Whom my wife calls “that really good looking guy from Hawaii who follows you on Twitter.” ↩
-
An in joke among people who edit their Apache settings. ↩
Combining and printing many emails
June 15th, 2010 at 4:21 pm
I’m often faced with the need to gather up and print out all the email I have on a project at work. I’ve written before about how I organize messages in folders by project—and use MsgFiler to help with that—so the gathering part is taken care of. What about the printing?
Let me first agree with those of you who think printing emails is a huge waste, the kind of thing that clueless old executives have their secretaries do because they’re too “busy” to learn how to use email. But I often don’t have a choice; I need to generate paper copies of the email because those “busy” executives are my clients. (This is why I blog pseudonymously.)
So, how do you print a bunch of selected emails without wasting a lot of time or paper? You could use Mail’s Save As… command from the File menu. That will combine all the selected emails into one RTF or plain text document that you can open in whatever application strikes your fancy and print from there. Unfortunately, the plain text version is kind of ugly and the RTF version goes too far in styling the text.
The gray and blue text won’t print out well on a monochrome printer and won’t photocopy well, either.
A better solution can be found by modifying this old tip at Mac OS X Hints. The tip describes an Automator action that
- Grabs all the selected messages,
- Combines them, and
- Creates a single new Mail message from the combination.
I’ve altered it just a bit, changing the last step from creating a new Mail message to creating a new TextEdit document.
The advantages of this are that all the text is black and the messages are separated by decorative lines, better for printing, photocopying, and reading.
I keep the Combine Messages workflow in my ~/Library/Scripts/Applications/Mail folder, where FastScripts can find it and make it available whenever Mail is the active application.
The font is big enough to still be readable when I print the combined document two-up. Along with duplex printing, this keeps the paper waste to a minimum.