ViewSourceWith, Thunderbird and mail editing

ViewSourceWith (VSW for friends) is definitively a browser oriented extension, using it with Thunderbird (TB) produces a very different experience.

VSW under TB allows users to view the mail message text (for example to inspect headers) but it doesn’t support any editing feature.

Under Firefox VSW offers textbox form editing (single and multiple lines) and I use daily the feature to edit GMail message content.

Editing rich textbox like GMail is a great feature, you can edit HTML code not only plain text, this is a great step ahead.

A couple of users asked me to add to VSW the ability to edit Thunderbird messages, not the raw view but a real edit feature in mail composition.

Well, now VSW (from version 0.3) can be used to edit Thunderbird messages, both plain text and HTML messages.

Technically speaking adding TB editing was enough easy using the nsIEditor, the same component used under Firefox with GMail.

I hope to post more details about the nsIEditor usage in VSW

Komodo logging facilities

Any programmer needs an easy way to log messages to trace bugs or to simplify problem diagnostic.

Mozilla extensions developers have two way to log messages; the dump function and the nsIConsoleService interface, both are invaluable developer friends.

Who lands on Komodo extension development finds a very rich set of methods to make log, so rich the dump and nsIConsoleService lose their value.

The namespace ko.logging wraps the koILoggingService methods and more over.

The code shown below print a warning and an error message

ko.logging.getLogger(”extensions.morekomodo”).warn(”warn”)
ko.logging.getLogger(”extensions.morekomodo”).error(”error”)

The getLogger works like a singleton, it uses a map to store requested loggers, this minimize the memory allocated reusing already-instantiated logger objects.

I use the practice to pass a string in “extensions.xxx” form. This naming technique simplify searching into log and splits komodo from thirdy parts (extensions) log messages.

There are two important caveats:

• How to use ko.logging namespace
• Where output goes

How to use ko.logging namespace

ko.logging is available to all elements overlaying komodo.xul (menus, tab panels, and  so on) but if you need it inside your xul dialog you need to use a ugly syntax like opener.ko.logging or opener.opener.ko.logging (when you call from a dialog open from a parent dialog).

Lucky a better solution consists to include javascript files and use the clean ko.logging syntax.

Add the line shown below to your xul dialog and all will work fine

<script type=”application/x-javascript” src=”chrome://komodo/content/library/logging.js” />

Where output goes

Output is visible when you start komodo with the verbose flag.

I use the script shown below in my Ubuntu box to always log messages, the script deletes the komodo.log file when its size is greater than 500000 bytes.

CURR_SIZE=` ls -l ~/komodo.log | awk ‘{print $5}’`
if [ $CURR_SIZE -gt 500000 ];
then
rm ~/komodo.log
fi

/opt/devel/mozilla/Komodo-Edit-4/bin/komodo 2>>~/komodo.log -v

Under Windows Komodo opens an annoyng dos window where output is displayed and I was unable to write it to file

Overlay popupset under Komodo

When you need to add elements to a popupset, for example a tooltip, you can find useful to overlay the extensionPopupSet element defined by Komodo.

It isn’t mandatory, you can add elements where you want (maybe) but I consider a good practice using element dedicated to extension authors.

The code shown below is taken from MoreKomodo 1.4

<popupset id=“extensionPopupSet”>
<tooltip id=“morekomodo-refresh-tooltip” orient=“vertical”>
<hbox>
<description value=“&morekomodo.refresh.pattern;” />
<label id=“morekomodo-refresh-tooltip-pattern” value=“” />
</hbox>
</tooltip>
</popupset>

Mozilla Gecko Extensions Developers on Linkedin

When, a couple of months ago, I created the Extension developer group at Linkedin I could not imagine people subscribes to it…

Now we are a little group but I hope to create a centralized place where smart people can share its professional knowledge about XUL.

Bear in mind this is linkedin group so isn’t a strictly technical related group.

Anybody using XUL in professional environments can join the group and describes what he/she expects from a professional XUL world.

Open a tab using FUEL on Firefox 3

I want to migrate to Firefox 3 and stop compatibility with FF2.x so I’m starting to use intensively FUEL.

Today I’ve replaced the old “open new tab” code shown below

newTab : function (url) {
const newTab = getBrowser().addTab(url);
getBrowser().selectedTab = newTab;
}

With the FUEL version

newTab : function (url) {
var uri = Components.classes["@mozilla.org/network/io-service;1"]
.getService(Components.interfaces.nsIIOService)
.newURI(url, null, null);
Application.activeWindow.open(uri);
}

Onestly I found so complicated the FUEL approach.

Why I need to create an URI?

Why open doesn’t work with a simple string?

BTW FUEL is great

Overload same xul element twice

My extension MoreKomodo overloads many elements

• command set
• toolbar buttons
• menu items
• find results tab

Due to my laziness I’ve added all these overloaded elements in main morekomodoOverlay.xul file.

It contains not-strictly-related code all together, for example the find results tab code is separated from other UI elements.

I’ve found very useful to overload more than once the same element inside chrome.manifest to isolate xul code and also javascript code.

It’s very easy

overlay  chrome://komodo/content/komodo.xul chrome://morekomodo/content/modokomodoOverlay.xul
overlay  chrome://komodo/content/komodo.xul chrome://morekomodo/content/findResultsOverlay.xul

That’s all folks

Annoying RadioStateChange usage

radiogroup is the worst XUL widget I’ve ever used, its usage is made boring due to RadioStateChange listener but the real annoying behavior comes on when you want to change radio selection from code.

It is very innatural because changing radiogroup’s selectionIndex doesn’t trigger RadioStateChange and you need to create an event by hand and trigger it.

var myEvent = document.createEvent(”Events”);
myEvent.initEvent(”RadioStateChange”, true, true);
document.getElementById(”radioGroup”).dispatchEvent(myEvent);

But this is not sufficient, the RadioStateChange handler is called twice, the first one to “unselect” and second one to “select”.

Doesn’t exist a simple manner to determine if handler is called to “unselect” or “select” so you can’t use the radiogroup’s selected propery.

The solution consists to test all radios selected property to find the checked element.

if (document.getElementById(”folders-radio”).selected) {
…
} else if (document.getElementById(”files-radio”).selected) {
…
}

How to detect XUL trees scroll event

My extension VisualDiffer contains two nsITreeViews that must synchronize scrolling, when user scrolls one the other tree moves the selection to the corresponding row.

Apparently XUL trees don’t have any event handler to intercept scrolling operations so I run the risk to became crazy.

After days spent to find a solution (using google) without result I’ve tried to use the DOMAttrModified event and amazingly it worked.

First I add a listener to the tree (VisualDiffer adds listeners to left and right trees)

document.getElementById(“left-tree”).addEventListener(“DOMAttrModified”,
function(event) { gFolderDiffer.onLeftScroll(event);}, false);

The onScroll simply checks if event.attrName is “curpos” and if it’s true the tree has been scrolled by user

onLeftScroll : function(event) { if (event.attrName == “curpos”) {
rightTreeView.treebox.scrollToRow(leftTreeView.treebox.getFirstVisibleRow());
}
}

This solution works fine but maybe exists a better way…

VisualDiffer: a new Komodo extension

When I migrated to Ubuntu I loose some important developer tools like UltraEdit and Beyond Compare two closed-source commercial applications representing the state-of-art like editor and file comparator.

I’ve created MoreKomodo (the original name was UltraKomodo ) to add to KomodoEdit the UltraEdit features I need.

Folders and files comparison tools under Gnome are poor so I’ve decided to create my own differ application based on KomodoEdit for at least three reasons

KomodoEdit is open source

KomodoEdit is XUL based so I can develop re-using my know-how

KomodoEdit is multiplatform (thanks to Mozilla Gecko Engine)

Finally I’ve finished the first stable version of VisualDiffer, it misses many features but I hope to add them.

How to get element style values from XUL (or HTML)

I’m working to my Extend Firefox 2 Runner Up winner Table2Clipboard.

Many users tell me to add a simple feature, exclude cells having style display: none.

The solution is so straightforward that I could not believe after initial implementation.

You can style an element using CSS selectors

.invisible {
display: none;
}

<span id=“invisibleSpan” class=“invisible”>I’m invisible man</span>

or using the attribute style attribute

<span id=“invisibleSpan” style=“display : none”>I’m invisible man</span>

These two ways can both simply handled using getComputedStyle

var spanElement = document.getElementById(“invisibleSpan”);
var style = spanElement.ownerDocument.defaultView.getComputedStyle(spanElement, null);
var displayValue = style.getPropertyValue(“display”);

That’s all folks!!

Obviously you can use any CSS attribute not only display.

Pay attention to ownerDocument.defaultView, you should use window.getComputedStyle() but under XUL this doesn’t return what you expect.

getComputedStyle can be used in normal unprivileged HTML code, too.

getComputedStyle is a W3C standard and is present on Internet Explorer, Opera and Safari, too.

Little things make developer life easier.