Operator 0.7a is available. This is an alpha release. Really.

You probably won’t notice anything obvious that has changed, but under the covers, things are very different. Here’s a list of some of the changes:

• Complete rewrite of parser and actions system
• Experimental support for species and XFN (These probably won’t be in the official release)
• More complete support for hCard and hCalendar
• Exporting a contact or event now gives you the option to save it to disk
• You can choose to not remove duplicate microformats
• Various bug fixes
• Ability to drop in Brian Suda’s X2V transforms to compare results (More info on that later)
• REMOVED: Ability to have default handlers for a given microformats

The new actions system is in flux right now, so I’m not giving any detail on how to write to it yet. Old handlers will still work, so if you have those, just drop them in.

If you find bugs, please report them as comments to this post.

As per my social contract, all code has been run through JSLint and migration from three versions of Operator have been tested.

Enjoy.

Why does it seem that every piece of software needs to be rearchitected at least once or twice?

So after chatting with Andy Mitchell about his Webcards work we decided to collaborate to try to avoid duplicating effort. I’m just about done with phase one of that effort.

The results of this effort include:

• Moving to a unified non Operator specific, non browser specific microformats parser.
• Moving to a unified actions architecture (Extension specific right now, but we’re working on that.)
• Nearly complete support for all included microformats.
• Ability to use legacy handlers.
• Ease of adding new microformats (I’ve added XFN and species just for fun).

After much internal struggle, I decided to actually remove one of Operator’s options because I think I was trying to hard. Operator has two modes, Actions and Microformats, and within Microformats, you could choose to have a “default handler” or display all handlers. If you chose not to display all handlers, you would get a similar UI (toolbar buttons), but they would only invoke the default handler. It seemed logical when I wrote it, but this function (if needed) can be emulated by actions. I hope no one complains about my removing this.

Visually, everything else remains the same, except I cleaned up the names of some of the actions. It’s really only the guts that have changed. Obviously there’s the potential for new bugs in this implementation, so I’m trying to get something out this week to start some testing.

If you have written handlers for Operator, please let me know so that I can make sure my legacy code is working. I’m not going to explain how to write to the new action API yet since it is not baked.

Thanks!

Update: This code is now contained in Microformats.js.

One of the things I’ve run into with Operator is learning how to parse microformats correctly. Instead of keeping the knowledge I’ve found to myself, I’ve decided to work with Andy Mitchell and create a generic cross browser microformat parser in JavaScript, tentatively called ufParser. That’s the reason I’ve been so quiet.

The parser allows for the creation of definition files for microformats, so that new microformats can be added to the parser easily. So far I have all of the Operator microformats done (hCard, hCalendar, hReview, hResume, geo, xFolk, rel-tag) and I have done XFN.

We’re also investigating the potential to create more generic actions as well (but I’ll maintain compatibility with old style Operator actions).

The next version of Operator will definitely use the new parser, so there might be some regressions here and there. Hopefully we’ll get them solved quickly

Stay tuned. I’m hoping to have something in the next week or so.

The official release of Operator 0.6.2 is available.

Here’s a full list of new features:

• Multiple languages available thanks mainly to babelzilla.
• Fix for the tabbing interaction bugs
• Options menu added to statusbar and toolbar button menu
• xFolk support (needs to be added explicitly in Options if you are not a new install)
• tag support for ma.gnolia.com
• Improvements to adding calendar entries
• include-pattern support for hCard and hCalendar
• Implied “n” optimization for hCards
• Improved debugging dialogs to use text area instead of alerts so they can handle large data and can be copied
• When debug mode is on, microformats with invalid items are bolded
• When debug mode is off, invalid microformat errors are placed in the Error console
• When you are in microformats mode with all handlers and have debug mode on, you get an additional menutem called “Debug” that displays the source and internal representation of the microformat (no more keystrokes)
• Selecting an invalid microformat displays error and source in the same window
• Operator now follows the bookmarks toolbar conventions for opening new windows and tabs. This includes:
  • Opening links in the current window by default
  • Middle click opens in a background tab
  • Shift+click opens in a new window
  • Ctrl/Ctrl+Shift open in a new tab based on the hidden preference browser.tabs.loadBookmarksInBackground (which is the opposite of Select new tabs opened from links – see my previous post)
• If you right click on a microformat, the microformat handlers show up on the context menu
• I have added an experimental feature for highlighting microformats that can be turned on in preferences. Not only does it highlight microformats when you hover over them, when you select microformats in any Operator menu, they are highlighted on the page. Please give me feedback on this item.

Here’s my social contract status for this release:

1. All code was run through JSLint
2. All handlers were tested
3. All migrations were tested
4. This release contains safeguards against leaving in debug messages in
5. I learned more XPath and was able to use it in more places to improve performance
6. I made multiple beta versions available before the official release
7. I fixed every bug that was reported so far

Note the “Extra Extra” tab in Debug is there for a reason – I’ll be posting about that soon.

Thanks for your support!

http://www.kaply.com/operator/operator.xpi

I added a few more features, so I need more testing. After this, I am totally feature frozen for the 0.6.2 release.

New features include:

• Operator now follows the bookmarks toolbar conventions for opening new windows and tabs. This includes:
  • Opening links in the current window by default
  • Middle click opens in a background tab
  • Shift+click opens in a new window
  • Ctrl/Ctrl+Shift open in a new tab based on the hidden preference browser.tabs.loadBookmarksInBackground (which is the opposite of Select new tabs opened from links – see my previous post)
• When you are in microformats mode with all handlers and have debug mode on, you get an additional menutem called “Debug” that displays the source and internal representation of the microformat (no more keystrokes)
• Selecting an invalid microformat displays error and source in the same window
• If you right click on a microformat, the microformat handlers show up on the context menu
• I have added an experimental feature for highlighting microformats that can be turned on in preferences. Not only does it highlight microformats when you hover over them, when you select microformats in any Operator menu, they are highlighted on the page. Please give me feedback on this item.

Thanks again for your support!

OK, after opinions and debate, here’s what I’ve come up with.

I’ve combined the source view and the internal representation into one tabbed window so I only need one action to display it.

For now, that action will only be available when you are in microformats mode with all handlers displayed AND debug mode. When that is done, you will have a new menu in the handlers that says “Debug” that displays the information. I might add a keystroke/mouse action later.

When a microformat is invalid, clicking on it will display the same window (again, debug mode only)

I am going to honor the browser settings for Ctrl/Shift behavior for opening new windows. This however has me in a new quandry.

Here’s the note I sent to the Mozilla usability folk (Mike Beltzner):

I’m looking into making operator honor the browser preferences related to opening links (in tab, in tab background, in new window, etc.)

On investigating this problem, I found that there are two prefs that control this functionality;

browser.tabs.loadBookmarksInBackground

and

browser.tabs.loadInBackground

browser.tabs.loadInBackground is used for content, and browser.tabs.loadBookmarksInBackground is used for chrome (I’m guessing mainly bookmarks)

The user can’t change browser.tabs.loadBookmarksInBackground easily – the pref UI only changes browser.tabs.loadInBackground.

So my question is, which preference should Operator use for opening links (what would a user expect)

Would they expect it to behave similar to content or similar to bookmarks (chrome)

Note the biggest difference here is what happens when Ctrl and Ctrl+Shift are pressed when opening a link.

Incidentally, by default these preferences are opposite which makes for a horrid user experience.

Create a new profile in Firefox 2.

Hold Ctrl key. Click on a link in content. Then hold Ctrl and click on Getting started in the toolbar – two different results. That sucks.

Thanks for your input.

More opinions welcome

I need to make a change to how Ctrl (and maybe Shift) key works in Operator and I need some opinions.

Currently, holding down the Ctrl Key when clicking on an entry in
Operator displays the HTML source and holding down the shift key when
clicking displays the content as I store it in an internal structure.

Unfortunately, my choice of the Ctrl key was a bad one, since the Ctrl
key is used to affect tabbed browser behavior. I’d like to change
Operator so that when the Ctrl key is held down when clicking, it
opens the web page specific to the operator action in a background
tab.

My choice of Shift was also bad, since Shift forces links to open in new windows.

The only keyboard action I’m left with using is Ctrl+Shift at the same
time (alt isn’t available).

So, here’s the question.

Of the two actions I provide, which is the most useful to microformat
developers, seeing the source of the microformat or how I interpret
it?

Should I assign the Shift key to displaying the microformat and
Ctrl+Shift to displaying my internal representation (since I may be
the only one that uses it). This would mean I couldn’t use the Shift
key to open a new window.

Alternatively, should I simply add menu items that correspond to these
two actions when Operator is in debug mode and get rid of the
keystrokes completely.

Or perhaps a menuitem to display the HTML, and the hidden action (Ctrl
key) displays the internal representation.

Or maybe have Ctrl and Shift do exactly what they do today only in debug mode?

Thanks in advance for offering your advice.

Per my social contract, I am making 0.6.2 beta available before placing it on addons.mozilla.org.

It’s available at http://www.kaply.com/operator/operator.xpi

Significant items in this release include:

I have tested this release significantly, including running JSLint against all code, testing migration from Operator 0.5 and 0.6.1, as well as starting a test suite. If you find problematic pages, please add them to the test suite.

Please report bugs here.

Thanks!

Jonathan Watt pointed out some preferences you can set to ensure that the JavaScript code in your extension is “clean.”

javascript.options.showInConsole set to true causes chrome JavaScript errors to be displayed in the JavaScript console. This preference is essential when you are writing/debugging your extension. If you don’t have it set, your extension will simply not work and you won’t know why.

javascript.options.strict set to true causes JavaScript to parsed in such a way such that you will see errors about bad code on the console. If I had set this preference, I would have found my problem.

In my social contract, I taked about using JSLint.

There were two problems reported with the current release of Operator that were very strange when I heard about them. One was that Firefox didn’t honor the “Show the tab bar when only one tab is open” preference anymore and the other was that external links opened in new windows. I spent a bit of time debugging the problem and tracked it down to this code:

  disable: function()
  {
    toolbar = document.getElementById("operator-toolbar");
    toolbarbuttons = toolbar.getElementsByTagName("toolbarbutton")
    for(var i=toolbarbuttons.length - 1; i>=0; i--) {
      if (toolbarbuttons[i].id != "operator-options") {
        toolbarbuttons[i].setAttribute("disabled", "true");
        toolbarbuttons[i].label = toolbarbuttons[i].getAttribute("origlabel");
        toolbarbuttons[i].setAttribute("label", toolbarbuttons[i].label);
      }
    }
  },

Do you see the problem there? Because I didn’t have “var” in front of toolbar, I was affecting the global variable toolbar which was causing all the problems that people were seeing. Anytime an extension uses a variable with a common name without putting “var” in front of it, it risks overwriting other global variables in the browser.

Running JSLint through my code with the “Detect undefined variables” option would have found this problem and other problems as well. When I used JSLint, I found many cases where I had done this and I was able to easily find and fix them all.

Some of the other things I was able to fix as a result of JSLint included missing semicolons, unnecessary global variables, using == where I should use ===, as well as general cleanup. One error in particular (Weird construction. Delete ‘new’.) encouraged me to reevaluate some code I had written and I was able to clean it up considerably.

So I would encourage you to at least attempt to run JSLint against your extension to make sure you aren’t creating any side effects you don’t intend.

Note that there is one construct that JSLint complains about that is very common in Mozillla/Firefox source code:

Components.classes["@mozilla.org/embedcomp/prompt-service;1"]
                           .getService(Components.interfaces.nsIPromptService);

JSLint would prefer you wrote it like this (note the location of the period)

Components.classes["@mozilla.org/embedcomp/prompt-service;1"].
                            getService(Components.interfaces.nsIPromptService);

I went ahead and made this change in my code to avoid seeing the JSLint errors, but your mileage may very.