Firefox theme for OS X

I had to recently recreate my Firefox profile again, so I've been (one at a time) reinstalling addons as I find I need them.

I realised today that I needed to install the delicious plugin, so a quick search of the word "delicious" and up pops up a search result of a theme called "grApple Delicious".

On closer inspection it looked like a Safari style theme for Firefox. I've always been a bit niggley about the default Firefox theme on OS X, but it's never irked me enough to decide to try another theme. With this theme staring me in the face I decided "why not".

Here is a screen shot of what it looks like:



Ok not 100% perfect. Everything at least fits the OS X look and feel (which I never though the default Firefox theme ever did) and even the close button on the tabs are on the correct side of the tab (the LEFT hand side, dammit!). The tab itself is not joining the top half of the frame though, is the wrong shade of grey, and the spinner / favicon is on the left hand side of the tab which looks awkward.

A bit of googling reveals the original site which created the theme, located at takebacktheweb.org. A quick look and I notice there's another grApple theme they've created called Yummy. The screenshot looks like it addressed the niggles that I had, so I download the theme. Screenshot of it running on my box is below:



They are minor improvements but I think it just adds that little extra bit of polish. The tabs are the right colour, the spinner is on the right hand side of the tab, and they are no favicons on the tab (favicon is only displayed on the location bar).

Perfect. My new default Firefox theme on my Mac :)

e-texteditor

Being an old Linux user from way back, my default choice of text editor has always been vi. When editing shell scripts, vi; when coding, vi; taking notes vi.

When I started my first development job and moved over to Windows I brought vi with me.

Sure there was Eclipse and TextPad but every now and again I'd encounter something where I need to do a column editing function, or a search and replace via regular expression, or just a very large file that I needed to load up which didn't cause the entire OS to hang.

Being a developer involves working in a team, and one time or another, they'll be a developer at my computer debugging a problem who would encounter vi for the first time. Unable to comprehend the reason they need to go into insert mode to type something, they would give up exasperated, stating that I should use a real editor, like EditPlus.

I've given nearly every single Windows editor a try and haven't found anything that would easily replace the functionality that vi provided.

Simple things like "find as you type", and highlighted search results would be basic criteria for me (note, both these features have made it into browsers like Firefox and Chrome, which only goes to show where all the innovation currently is).

Enter e-texteditor. Recommended by an old co-worker of mine, and branded as a TextMate clone for Windows the editor it is very sparse. I did my usual barrage of tests, first thing being "find as you type" and to my surprise what do I see:

Not only was there "find as you type" but as if almost like I was in vi again, highlighted search results!

And to replace the highlighted results, no need to open up another search window but instead, place the cursor in the "replace" text box and hit the "all" button. Everything highlighted is now changed, and is an easy way to see (just by sliding around the document and looking for highlighted text) what is going to get changed with a find/replace before actually performing a find/replace.

A bit more digging around and I find it has a built in indent guide, which draws vertical lines at where the indents are.

The indent is a bit smarter than usual too. Not only can you specify how many spaces a tab is, but you can specify soft tabs (i.e. an indent is equivalent to 4 spaces). This means every time you hit tab 4 spaces will be used but also (when using the cursor keys) if you move back over those 4 spaces it doesn't traverse one space at a time but 4 spaces at time.

Another nice touch is that to display non printing characters, i.e. spaces, tabs, carriage returns, instead of sifting through a menu option, all you have to do is highlight the area and all the non printing characters are displayed

My second test is usually column editing. Most text editors usually need to be put in a column edit mode, but e-texteditor all that is required is that instead of using shift and the cursor keys to highlight the text, you use alt instead and can highlight a column straight away. Then ctrl-c to copy, or just straight away type over the selected columns.

This hooks in with another nice feature they have where if you wanted to modify a couple of words in a document, you just highlight each word individually and just start typing. When select these terms, you have essentially put the cursor in those highlighted positions and when you type you literally see yourself type in half a dozen places at a time.

This fits in nicely with the column editing paradigm. As when you select a column, you are essentially just selecting that word. When you copy, push delete, or just type, you are typing over that word.

There is a video of this on the home page of the e-texteditor homepage which explains this better than I can explain it.

Finally regex, which works a charm. It's a little finicky to get to (I can't seem to find a keyboard shortcut for it) and you have to click the little magnifying glass icon next to the search to enable it, but the regexes themselves I haven't found anything fundamentally wrong with it so far. But that could be the fact that I've only been doing rather primitive regexes so far.

One more feature I'd like to highlight is that it is compatible with TextMate bundles (syntax highlighting definitions) so nearly any language you can think of is supported.

There is also a keyboard binding to switch between different bundles in the document, which comes in handy when editing a marked up file which contains a soup of HTML, CSS, JavaScript, scriptlets, etc and you want to highlight the different parts of the document as it isn't available in a single bundle.

This was about 2 months ago and since then I've gotten a lot more use out of this. Strangely also reducing my reliance on vi, and have even gone as far as purchasing a license!

I haven't really got any niggles with this except it crashes a lot more than I would like it to (not that often but a text editor shouldn't crash at all) and it also has trouble loading large files (i.e. files larger than 100megs) which vi just eats for breakfast.

I think vi will still be around a bit but I think I've managed to find an editor which I can use on a day to day basis where people won't freak out using when jumping on my machine.  

Gmail Themes

Who says google doesn't know design.

One fatal flaw with Open ID

If your Open ID provider is down, you'll no longer be able to log into any any sites which you've registered with that provider.

Ok is all ... 

Knowing when to break the rules

One thing which has irked me a lot recently is a piece of UI "correctness" that I've noticed when using Chrome.

Note the screen shot below:



If you can manoeuvre your mouse into the area that I've circled (in between the tab and the "plus" button) and click and drag the mouse around, you'll notice that the entire Chrome window starts moving around. The reason for this is that when you click this area, you are (essentially) clicking on Chrome's title bar and (as a feature with most OSes) when you click and drag a window's title bar, you are able to alter the position of the window.

What's wrong with this behaviour? Nothing really. It is extremely hard to trigger, and when triggered (and after having a good look at the UI) relatively easy to figure out why your Chrome window has repositioned itself about 5 pixels to the right, instead of opening a new tab.

Sometimes though it's ok to break the rules.

There's a rule in computer science called Fitz Law, which talks about how easy it is for a person to click on something on the screen with the mouse.

Long story short, the easiest places for a person to click are (in order of easiest to hardest)

1. Where the mouse is currently
2. At the edges of the four corners of the screen (all four corners are second equal)
3. And all third equal, anything hard up on any sides of the screen, i.e. hard top, hard left, hard right, and hard bottom of the screen
4. And for the purposes of this example: everything else
   

The reason is that to hit these positions, you can just "flick" the mouse right to each of the four corners of the screen (or to the hard left, hard right, etc) and don't have to slow down to find the exact spot, or go back again if you've overshot.

If you're using a Mac, to open the Apple menu you don't have to click right on the "Apple" icon (even though the screen shot below gives that impression). Just click on the top left hand corner, and the menu opens. Same with the spotlight window (on the top right hand corner).



If you're on a Windows machine, same with the Start menu and also the Task Bar. Notice how though, on the Task Bar (below) each task box doesn't actually extend to the bottom of the screen. If you click hard bottom of the screen, underneath the task, the mouse will actually "jump" up 3 pixels and selects the task (go on, give it a try if you don't believe me).


Which brings me back to Chrome's title bar "bug" which should (IMHO) open a new tab if the surrounding area around the "plus" button is clicked.

Competition in the spreadsheet space

I got a reply from some smart arses regarding my last post on more competition in the spreadsheet space and thought I'd post the following screenshot as a sign of what I overlooked:

Attachments with mail.app

I've always been confused with the way that attachments are handled in mail.app (the Mac's default email application).

Traditionally, if you'd wanted to attach a file to an email you'd just drag it into the composition window and (usually in a separate location in that window somewhere) there'd be a list of attachments that the email had.

Once sent, on the receiving end, you'd receive the text of the email, and a list of attachments (which you could then and download or preview individually).

On the other hand when dragging an attachment into the compose window of mail.app, it doesn't drop the attachment into a separate section of the email, but inserts the attachment inline.

This causes a few problems with some mail applications as:

1. There usually isn't an easy way to download images which are inline
2. You can't select all inline images and download them all in one hit
3. And more an annoyance than a bug, but when downloading the email, all the images will be downloaded there and then, instead of just downloading the text
   

The worse thing was that it was inconstant. Sometimes it would send the attachments inline and other times it wouldn't. But this was only on machines which weren't using mail.app. When using mail.app though, all images would always be displayed inline and there would also be an option to download all inline images in one hit. (Yes things are beautiful within Apple's wall garden).

I needed to find a way to send emails from mail.app so that people receiving my emails had a way to download the images I sent.

So I did a bit of googling and found an option (which many people claimed on message boards) called "Always send Windows-Friendly Attachments" which would fix the problem



A bit of experimenting with this and no. With respect to this problem this option doesn't do anything at all.

After spending a bit more time searching on the Internets I decided to check out the problem myself and maybe it was the way that mail.app was sending the emails and differences in the MIME encoding.

Viewing the source I realised that on emails where attachments were inline, the email contained MIME types of both plain text and HTML, and emails where attachments weren't inline the email only contained plain text. I did a quick test email to myself (note how I've got the word HTML underlined - more on this later):



And receiving it on the gmail end:



This confirmed one half of my suspicion. (Note how in the gmail screen shot there is no option to download the image which is attached)

I then decided to send this email again but forcing plain text this time (keyboard shortcut apple-shift-t):



Loading up in gmail shows up as expected, with no inline images, and an option to download the image.



So the reason for the inconstancy? Even though I've sent emails which have had the attachments downloadable (like in the second screen shot) and I've never forced plain text before (until this day), is that mail.app (even though I've set it to always send rich text emails) only sends emails in HTML if your email contains HTML formatting (the reason why I underlined the word HTML in my first email).

So looking back in my history, it seems that most cases that mail.app has inlined images is when I've sent an email with a link (HTML formatting) and an image from that link.



So in future, if I am sending a set of photos, I'll be forcing plain text emails. Otherwise it's the lolcat image with the relevant hyperlinks.

(Or I could just disable HTML emails altogher)



Note: In the raw email sent, mail.app doesn't just compose the email with the plain text at the top and the attachment at the end. It actually sends a plain text MIME component, then the attachment (the inline image) then another plain text MIME component at the end.

Most email readers (gmail included) seem to have trouble displaying this image inline when surrounded by plain text components, and instead puts all plain text elements together and provides an option to download the image.