Recently in Hacks Category
I spent a bit of time researching how to do this - there just had to be a way. It turns out that TiVo Desktop plays nicely with LAME and will transcode on the fly. This is, of course, a bit more lossy than it could be, but I'm ripping discs into 190kbps AAC files and they sound fine to me.
First I found this hint that taught me about LAME, but all I heard was static. So I dug and then I found a posting here outlining a fix. I tried it and it absolutely worked. So you don't have to sift through the postings, I will copy the post here for you.
gerickson posted:
Thanks to everyone here who helped me figure out my AAC -> static issue running on a Mac Pro w/ Mac OS X 10.4.8 and TiVo Desktop 1.9.3 (008).I tweaked the recipe slightly and installed the following script in "/Library/Application Support/TiVo/lame" since SoundConvert checks there first:
#!/bin/sh
exec /usr/local/bin/lame -x $*However, in the process of doing this, I noticed that TiVo Desktop leaves around zombie processes when you skip AAC tracks. I did a 'ps -jx' and noticed tens to hundreds of sleeping 'SoundConvert' and 'lame' processes.
Has anyone modified the above script/wrapper to reap any such zombies before exec'ing the next iteration of 'lame' on the "current" track?
I have not tried to solve the zombie process problem. I left it in for full disclosure and all.
This post is mostly for me to find later when I inevitably screw around, break this, and wonder how I got it working in the first place.
CamiTools vastly improves my experience with Camino 1.0. If you haven't tried it and you do use Camino, I would strongly urge you to give it a try.
At the time of this writing, the current version of CamiTools is 4.4 and the current version of Camino is 1.0. I have come across what appears to be a bug with the Style tab and have reproduced the issue on a PowerMac G5 and a MacBook Pro, both running OS X 10.4.6. In this post I will detail the apparent issue and a workaround which has been tested and shown to work.
Within the CamiTools preference pane there is a tab marked Style. Here you can create a stylesheet that will override default settings for a site and give you a custom display - very handy if you find the functionality of a given site excellent but aren't too fond of some of the colors, fonts, or font sizes that they have chosen.
Unfortunately it doesn't seem to work. When I have created a style, saved it, checked the box marked 'Active Style', and restarted Camino, I have found the style is not in effect and the checkbox is unchecked.
We can begin recreating the issue by clicking the button marked 'Examples'. This will generate two css files - one for www.google.com and one for "anydomain". For the purpose of this example, we'll focus on the google style (which has been named ct_www.google.com.css). Go ahead and make any edits to the style that you'd like, then check the box marked 'Active Style', click the 'Save Style' button, and restart Camino. Now surf to Google. If it looks different per your styles, apparently this bug does not affect you. I'm interested in hearing from you if this works for you!
Assuming you're like me and the issue is effecting you, we can get started on the workaround. Start by closing Camino and opening up a finder window. In your finder window, navigate to home:Library:Application Data:Camino:chrome (that's ~/Library/Application Data/Camino/chrome for we command line ninjas). In here you'll see a few key files which include userContent.css, camistyle.css, and ct_www.google.com.css. Using your favorite text editor, open up userContent.css. You'll see a line that reads:
@import url(camistyle.css);
This line imports the camistyle.css file. If you open that file you'll see it is empty. If you open the ct_www.google.com.css file you'll see your google style. We can now add an @import line similar to the above to either camistyle.css or userContent.css. Either one will work. It is my guess that the Style tab in CamiTools is supposed to add the line to camistyle.css, so in my implementation I chose to add the following line to camistyle.css instead of userContent.css.
@import url(ct_www.google.com.css);
Now restart Camino and surf to Google. If all went well, you should see your style applied. If you look at ct_www.google.com.css within the Style tab you will see the box marked 'Active Style' checked, further proving my contention that this is the intended behavior.
All of these findings have been reported to the author of CamiTools, and hopefully we'll see a bug fix soon.
The lack of RSS support is one of the major shortcomings of Camino as a browser. Even Firefox has an extension (FeedYourReader) that plays off its live bookmark feature. Yet we lowly Camino users have nothing to speak of. In lieu of any real support, folks have written some nice AppleScripts for CamiScript to discover feeds and open them in your reader.
This alternative seemed better than nothing, so I ran off to the CamiScript Script Repository in search of a script that would work. There before me were three scripts. One worked with NewsFire, another with Vienna, and a third was generic. I use NetNewsWire Lite, the full version of which is supposed to be the most popular RSS reader out there, so the only option that would work would be the generic feed script. But there's a catch. There's a section of your preferences called "Link from other application" and the script requires that you select "Reuses the frontmost window."
I'm a guy who likes to open links from other applications in a new tab, so this option just wasn't going to cut it for me. I decided to poke and prod through some of the AppleScript code in the hopes of discovering the secret to telling NetNewsWire to open the feed. And within the generic feed script I saw the secret. The script actually did nothing more than launch a javascript link in Camino. I puzzled out that AppleScript must still be considered an external application, and that's why the above option was required for the script to work. But a bookmarklet would do the job nicely.
So, without wasting any more of your time with my rambling, I present to you the bookmarklet. Add this link as a bookmark to get the bookmarklet. And the code? Just look at the link's destination to get it.
In a nutshell, the bookmarklet sniffs out feeds then directs you to feed:http://feedurl/. Your browser and reader should then be smart enough to know that url is destined for it and should act accordingly. The neat thing is that we'll probably be seeing more and more aggregators accepting feed: links, not just on OS X but on Windows and Linux too, making this bookmarklet functional on any browser and any platform.
I wish I knew the original author of the script so I could credit them directly, but the best I can do is say where I got it and hope for the best.
Not long ago I directed my readers (that's you) to a well detailed hack to tell the Weather widget that ships with Dashboard to show you the last time it updated. That solved one of my two big problems with the widget.
The other problem was a little bit more confusing. For longer city names, such as mine, I found it far more difficult to locate the clickable sweet spot on the city name that was linked to the AccuWeather website. Then I had an idea. It's just HTML and JavaScript, right? Well why not make something else clickable?
It seemed to me that the next logical thing to make clickable was the temperature. I looked through Weather.html and found a line that read:
<div id='temperature'>--</div>
I altered that line to read:
<div id='temperature' onclick='goToAccuWeather(event);'>--</div>
After opening a new copy of the Widget I found the temperature to be clickable.
Please remember, backups are your friend. As was suggested in the original hint, I recommend that you make a copy of Apple's original widget (found in /Library/Widgets) in your own local widget directory (~/Library/Widgets). The one in your home directory will replace the default one in the Dashboard bar, and you will have a pristine backup just incase.
Better late than never. In my travels a few weeks ago I found this hack to add the time of the last update to Apple's Weather widget for Dashboard.
The piece is very verbose and thorough, explaining what each bit of code does rather than brief instructions. Marc tested, G5 PowerMac approved.
So why would you want to do this? The short version is that the Weather widget only updates when you're viewing the dashboard (which saves bandwidth). So rather than glancing at the dashboard and knowing whether or not the widget already updated, the user ends up looking at the widget and wondering if the data is hours old or brand new. This isn't always the case - for example if it says it's sunny out and you're looking at the night sky through the window you know you haven't updated. But having that time there is pretty helpful - at least for me.
I, for one, appreciate this hack.