Posts Tagged ‘fluid’
A new Twitter SSB
June 12th, 2010 at 9:13 pm
With the coming requirement to use OAuth to sign on to Twitter, I’ve had to abandon my Dr. Twoot client program and have shifted to a new Fluid-based SSB of the Twitter home page. I’m using a userscript to reformat the page and make it narrower.
Two reasons I couldn’t adapt Dr. Twoot to OAuth:
- I’ve read in several places, including in Twitter’s developer pages, that JavaScript isn’t appropriate for OAuth because it exposes certain tokens that are supposed to be secret. Dr. Twoot is written in JavaScript.
- As important, I just can’t find an OAuth tutorial that I understand. Everything I’ve seen is all about Consumers and Users and Providers and getting credentials from one site to use on another. I’m not interested in any of these two-cushion internet bank shots; I just want to log in to one site and use it.
So, barring a last-minute change in Twitter policy, Dr. Twoot will stop working at the end of the month. I’ve looked into other Twitter desktop clients, but haven’t found any I like. I’m dead set against installing Adobe Air on my computer, which cuts down the number of available applications considerably. I tried Tweetie, but for some reason it isn’t nearly as compelling on the desktop as it is/was on the iPhone. I liked the customization options of Kiwi, but didn’t like any of the themes that came with it. I didn’t want to buy an application and then spend a bunch of time programming just to get an acceptable look.
Which led me to Fluid. In a minute I had a new application—called, with a certain lack of imagination, Twitter—that was a site-specific browser for the Twitter home page. It didn’t have the look I wanted, but I eventually hammered out a userscript that gave me a nice narrow view of the timeline that I could keep over by the right edge of my screen.
The sidebar is still available by scrolling to the right.
As you can see, I made the tweet input area taller and added the IM Fell font for rendering @DrSamuelJohnson’s tweets. Less obvious, maybe, is that I’ve boosted the font size and the line spacing a bit to make all the tweets more readable.
I knew from my earlier Twitter userscript that the Twitter home page loads jQuery, which should have made the reformatting easy. Unfortunately, the layout of the Twitter home page is a mess. You’d think it would be clean and simple: there’s a background image, a header, a footer, and a two-column content area—not much more complex than this site, really. But the HTML of the Twitter home page is a nightmare of <div>s within <div>s. Some contents are allowed to spill out of their containers, others aren’t. The two columns that make up the main portion of the page comprise a one-row <table>, which has a very 1990s vibe.
My first experiments in narrowing the timeline were very frustrating. Everything I tried that should have worked didn’t. I started Googling to see if anyone had solved this problem before me.
As it happens, there’s a userscript called Endless Tweets by Mislav Marohnić that, among many other things, very cleverly reformats the Twitter page to a narrow layout when the user resizes the window to a small width. I didn’t want to use Endless Tweets itself—it had some minor rendering problems in my tests—but it gave me hope that I could get the timeline narrowed if I just kept at it.
Success eventually came when I opened the Twitter home page in CSSEdit, a seldom-used (by me, anyway) application that came with the MacHeist 2 bundle, and started playing around with the widths of various elements. I kept track of the tests that worked and incorporated them into my userscript. Here it is:
1: // ==UserScript==
2: // @name twitdrang
3: // @namespace http://fluidapp.com
4: // @description Makes Twitter narrower.
5: // @include *
6: // @author Dr. Drang (http://www.leancrew.com/all-this/
7: // ==/UserScript==
8:
9: function getIMFell() {
10: $("head link:last").after('<link href="http://fonts.googleapis.com/css?family=IM+Fell+English" rel="stylesheet" type="text/css">');
11: }
12:
13: function twitdrang() {
14: $("#container").css({'width':'600px'});
15: $("#header").css({'width':'600px'});
16: $("div#wrapper").css({'width':'400px'});
17: $("#side_base").css({'width':'200px'});
18: $("ol.statuses li").css({'width':'400px'});
19: $("fieldset.common-form").css({'width':'400px'});
20: $("#update_notifications").css({'width':'250px'});
21: $("ol.statuses span.status-body").css({'width':'300px'});
22: $("fieldset.common-form textarea").css({'width':'375px'});
23: $(".actions-hover li").css({'width':'20px'});
24: // $(".actions-hover .reply").css({'float':'right'});
25: // $(".actions-hover .retweet-link").css({'float':'right'});
26: $(".actions-hover .retweet-link a").css({'display':'none'});
27: $(".actions-hover .reply a").css({'display':'none'});
28: $(".actions-hover .retweet-link a").css({'display':'none'});
29: $(".actions-hover .del a").css({'display':'none'});
30: $("ol#timeline .status-content").css({"font-family": "Lucida Grande", "font-size": "15px", "line-height": "1.3"});
31: $("textarea#status").css({"line-height": "1.4", "height": "4.2em"});
32: $("li.u-DrSamuelJohnson span.entry-content").css({"font-family": "IM Fell English", "font-size": "120%"});
33: $("li.u-DrSamuelJohnson.latest-status span.entry-content").css({"font-family": "IM Fell English", "font-size": "175%"});
34: }
35:
36: if (window.fluid) {
37: getIMFell();
38: twitdrang();
39: }
40:
41: $(window).scroll( function() {
42: twitdrang();
43: });
If you’re interested in a narrow Twitter SSB, follow the Fluid instructions to make an application that points to http://twitter.com, and then add this to the Userscripts folder. I call it twitdrang.user.js, but you can name it whatever you want. If you’re reading this well after the day it was posted, you should look at the twitdrang GitHub repository because it’ll have the latest version.
You may find that any time you post a new tweet, or update the timeline by clicking the “xx new tweets” link, the new tweets will not be formatted to the narrower width. That’s because those events don’t trigger the userscript. I haven’t yet figured out how to get that to work, so in the meantime there’s a kluge. See Lines 41–43 in the code above? They cause the reformatting function to be run whenever the window is scrolled. So if you just wiggle the scrollbar after the new posts arrive, they’ll narrow themselves down just like the others.
A kind word about Stickies
June 4th, 2010 at 1:35 pm
You may have seen this Lifehacker article from yesterday, about using Fluid and a small local HTML file to make a hideaway scratchpad for little bits of text. I heard about it from Todd Ditchendorf’s tweet today. I’m a big fan of Fluid’s, and love making site-specific browsers (SSBs) with it, but this is just a stupid idea. It’s “tips” like this that took Lifehacker’s RSS off my subscription list years ago.
Why is it a stupid idea? It’s certainly not because I’m opposed to homemade hacks; this blog is clogged with my homemade hacks (and those are just from the last few months). No, it’s because every Mac ships with a little application that does exactly what this hack is supposed to do and does it better. I refer, of course, to Stickies.
I used to think Stickies itself was stupid—who would want their screen cluttered up with colored rectangles? But that was before I discovered that Stickies has a magic power, a power known to the ancients back in the days when Mac OSes were numbered in Latin instead of Roman. It’s the power of windowshading.
Here’s a standard sticky.
And here’s what it looks like after you double-click the darker yellow strip along its top edge.
Time was when every Mac window could be rolled up like this by double-clicking on the titlebar. Now, double-clicking the titlebar causes almost every window to minimize itself into the Dock. Only Stickies retains the old behavior.1
Why is this better than minimizing any old text window to the Dock? Because icons in the Dock move around; a rolled-up window stays where you put it. I always have Stickies running with just one tall sticky that I keep tucked up just below the menubar near the right edge of my screen. As I find bits of text I want to save, I double-click the strip to unroll the sticky, paste in the text, then double-click again to roll the sticky back up. Every few days, I delete the bits of text I don’t need anymore.
This is clearly better than the Lifehacker tip. Like the Lifehacker tip, it’s free; but in addition it
- understands links dragged from your browser’s toolbar;
- holds images (OK, I don’t use that feature, but you might); and
- saves its state between launches.
Try doing that with an HTML <textarea> field.
-
The WindowShade X utility by Unsanity apparently gives an approximation of the old behavior. I haven’t used it. ↩
Dr. Twoot authentication redux
April 2nd, 2010 at 11:30 am
I decided that last night’s configuration instructions for Dr. Twoot (the world’s greatest Twitter client) were unnecessarily long, so I wrote a quick little configuration script that prompts you for your Twitter username and password and prints out the required authentication lines.
The script is called config.py:
1: #!/usr/bin/python
2:
3: from base64 import b64encode
4: from urllib import urlopen
5: from getpass import getpass
6: import re
7:
8: print '''Enter your Twitter username and password.
9: The password will not appear as you type it.
10: '''
11:
12: uname = raw_input('Username: ')
13: # pword = raw_input('Password: ')
14: pword = getpass('Password: ')
15:
16: url = 'http://twitter.com/users/show/%s.xml' % uname
17: uid = re.sub(r'\s*</?id>\s*', '', urlopen(url).readlines()[2])
18:
19: print '''
20: Copy the following two lines and paste into twoot.js.
21: '''
22: print "var UID = %s;" % uid
23: print "var B64AUTH = '%s';" % b64encode('%s:%s' % (uname, pword))
From the command line, cd into your drtwoot directory and execute
python config.py
You’ll be prompted for your Twitter username and password and out will pop two lines that will look something like this:
var UID = 987654321;
var B64AUTH = 'c21lYWdvbDpwcmVjaW91cw==';
Copy these and paste them into Lines 8-9 of twoot.js, and your copy of Dr. Twoot will be customized for your account. All of this is in the GitHub repository.
As you can see script connects to twitter.com to get the user ID number, but doesn’t store or send your password. As currently written, the password is not echoed to the screen. If you like to see what you’re typing as you type it, and you’re not worried about shoulder surfers, you can comment out Line 14 and uncomment Line 13.
Line 17 does a lot of work. It
- connects to Twitter;
- reads your publicly-available user data and puts it into a list of lines;
- extracts the third line of that data; and
- erases the
<id></id>XML tags and any whitespace, leaving just the user ID number.
Line 23 generates the Basic Authentication string by doing a base64 encoding of your username and password, separated by a colon.
I thought about having the configuration script edit twoot.js directly, but it didn’t seem worth the effort. Users who know how to create a site-specific browser with Fluid aren’t likely to object to a simple cut and paste.
BBC iPlayer site-specific browser
February 24th, 2010 at 10:00 am
As I’ve mentioned at great length in earlier posts, I use Audio Hijack Pro to record BBC Radio shows that are streamed over the internet but don’t come in podcast form. Until recently, I’d been using Safari to open the stream URL. Generally, this worked out fine, but if I wanted to browse while recording something in the background, I had to follow two rules
- Don’t open any sites that play sounds, as these will be recorded on top of the show.
- Don’t quit Safari when I was done browsing, as that will kill the recording.
Sometimes I’d forget to follow these rules and ruin a hour or more of recording. Whenever this happened, I’d try to fix the problem by swearing at myself, but that never seemed to work.
What has worked is creating a site-specific browser (SSB) for recording. I used Fluid1 to create an SSB, called BBC iPlayer, that opens a generic BBC page.
BBC iPlayer, then, is the application whose sound output gets hijacked by AHP.
AHP tells BBC iPlayer to navigate away from the generic page to the URL for the stream. Now I can browse in Safari without worrying that something I do will screw up the recording.
Luckily, the various scripts I wrote for getting the streaming URL from the BBC—all collected in this GitHub repository—are browser-agnostic, so they didn’t have to be edited at all. Only the settings in AHP itself needed updating.
I was going to use the current BBC logo as the icon for the BBC iPlayer SSB, but its horizontal layout doesn’t work well as an icon. So I found a screenshot of the old spinning blue globe logo (the one you’d always see during Monty Python’s Flying Circus) on this BBC logo history page and did a bit of editing.
It doesn’t look great at a small size, but it’s instantly recognizable to me.
One more thing: As you can see in the AHP screenshot, one of my upcoming recordings is of an episode of Radio 2’s semi-regular show, The Record Producers. The subject of this Saturday’s show will be Todd Rundgren. Obviously, I have no idea if the show will be any good (personally, I’m hoping they don’t spend too much time on Bat Out of Hell), but Todd fans will probably want to listen regardless.