Category Archives: greasemonkey

i (greasemonkey)

One of the projects I wrote was an indico uri shortening service, called i (or indigo, depending on how ugly “i” looks in context) but I wanted to go a step further. So I write a greasemonkey script so that I could get to indico pages without even loading the main page. This takes up very few pixels on the screen, making it much faster to get to the meeting pages.

Links

indigo page
GitHub repository

Overview

This is a rather simple script. It simply redirects (in a new tab) to the i page, which redirects to indico.

Screenshot

Screenshot of a tiny implementation of i
Screenshot of a tiny implementation of i

LXR tidy

When I was working on the CMS experiment I used their LXR a lot when browsing code. The interface was fairly basic and would return a poorly formatted (and unsemantic) HTML output, so I write a greasemonkey script to make the results easier to read. Within a couple of weeks of writing this code the developers improved the output, so this project never got any wider use.

Links

CMSSW LXR home
GitHub repository

Overview

The output is parsed and carefully separated into different results. These are then wrapped in more pleasant looking HTML, colour coded based on the file type (with characters for the colour blind) and the main modules are summarised to give an idea of the main users of a given piece of code.

Challenges

Challenge: The default output is terrible. Just terrible.
Solution: The default output was not even semantically correct (from what I remember there were no <html> tags) so I had a hard time parsing the DOM properly. Special character sequences such as << appearing in C++ code didn’t make things much easier. (Resolved.)

Screenshots

Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output after the tidy script is applied
Screenshot of LXR output after the tidy script is applied
Screenshot of LXR output after the tidy script is applied
Screenshot of LXR output after the tidy script is applied

greaseBox

In the mid to late 2000s I used to visit an LGBT social networking site, Thingbox. The site had many features, but the users wanted more. It was around this time that I was discovering how to use greasemonkey, so I put together many short scripts. Eventually I combined them all into a single script called greasebox that was very popular. It has been many years since it was maintained though, so I doubt it still fully works.

Links

Thingbox
Live page
GitHub repository

Overview

The website provides a huge amount of information via AJAX and HTTP requests, and this project required some clever reverse engineering to get right. When the scripts are combined they are modular, and they are executed in a specific order to prevent clashes. A few modules are inter dependent, so they are arranged in the correct order, otherwise it goes from least to most fragile. There is also a debug tool to see exactly whre things go wrong. There is also a detailed interface page where users can change their settings.

Unfortunately I don’t have a screenshot of the project, since it was developed so long ago (last touched 2011/02/05) and in browser scripting has changed a lot since then.

Challenges

Challenge: This had to use the Thingbox “API” properly.
Solution: Although Thingbox didn’t have an official API, I reverse engineered how things worked to make it do what I wanted. This occasionally required help from other users (eg to send friend requests) but was mostly possible on my own. (Resolved.)
Challenge: The content had to be intuitive and responsive to users’s needs.
Solution: This was one of the first projects where I had to see things from the point of view of the user and make things as intuitive as possible. The aesthetics of the project had to fit in with the Thingbox style, not only to look good, but to be usable. This meant that I had to deconstruct and understand the rationale behind the site design and the choices the creators made, which was very informative. I also had to pay close attention to requests and questions from users as they arose, which gave me a lot of insight into how to make things as easy to use as possible. (Resolved.)
Challenge: When combining modules the order mattered.
Solution: I had several modules that would go through and edit the content of the page. Obviously this would cause problems if it wasn’t done carefully, so I had to order the modules in the correct way. This was not trivial to do, but made management much simpler. There was also a dedicated debug module that would take information from the current session and print it to a div element that the user could attach to the page with a special command. This debug information allowed me to determine exactly how far the scripts got before a module caused a problem. (Resolved.)
Challenge: This project suffered from a sense of humour.
Solution: I was writing for a group of mostly well educated middle aged gay men, and as a result there was a lot of banter and humour. I would create puns for each of the single modules. (For example one of the running jokes was constant references to internalised homophobia, so I called the script that open external links in a new window “externalised homophobia”.) This did not help when I tried to combine the modules into a single script, and I will not be making that mistake again! (Resolved.)
Challenge: This needed cross platform and cross browser support.
Solution: This was probably the most difficult challenge to overcome. I would test in Firefox with a mac, but there were many users who insisted on using Window, Chrome, and sometimes even Safari. Each one had different nuances (including counter intuitive storage of information) that had to be understood to make features work. Although I tried very hard to make it work, there were some features that didn’t make it onto every browser. (Mostly resolved.)