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

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

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.

KomodoEdit and smart tab switch

Today I’ve discovered again (and again) other programmers have my same needs.

I do intensive use of tab switcher during my editing sessions, Control-Tab is my preferred key sequence.

When I need to use Eclipse I love the ability to access to the buffer list using the little arrow placed at buffer tabs end.

You can type buffer title to quickly focus the buffer or use arrows keys, very cool.

KomodoEdit offers very poor ways to move between views so I wrote my TabSwitcher to mimic Eclipse feature.

Today I’ve read a post on ActiveState’s forum where another user has my same needs and I’ve decided to share my bonsai extension with the community, I hope the community appreciates my work.

Maybe I should create a website page for TabSwitcher but I’m so lazy and maybe user feedback can be very low.

Central extensions repositories

I spend my time to created extensions based on Gecko expecially for

• Firefox, Thunderbird and SeaMonkey (all under Mozilla umbrella)
• Songbird
• Flock
• KomodoEdit/KomodoIDE

Every product has its own developer website where you can upload your extensions (Komodo hasn’t a dedicated upload zone).

From a visitor/user feedback’s point of view Flock is the best.

Flock addons site is cool I love it, extension informations are very complete, you can see also the locales supported by extensions.

Songbird has a cool addons site simple and very quick, extension informations are complete.

Mozilla with AMO is the most important but is also the worst.

The outsider KomodoEdit addons site not yet really exists, registered users can’t upload their extensions.
I hope Komodo guys take a look at Flock addons site if they decide to create a similar place.

From a developer feedback’s point of view Songbird is the best.
After signup you can immediately upload and publish extension on Songbird site, the upload process is easy and publication policy very developer friendly.

AMO upload mechanism is simple but publication mechanism is awful. I don’t like its approval mechanism based on sandbox, my RichFeedButton waits approval for an year.

Flock allows to upload extensions immediately after signup but publication waits approval, after a couple of days I’m yet waiting

The most mature and important addons site AMO, has IMHO the worst user/developer experience.

I don’t like so much Flock but it has a great develope/user website

Komodo and readonly behavior

Komodo editor handles read-only in a incomplete manner, at least for me.

The truly question is “what read-only means?” A file can be read-only but also an editor buffer can be read-only.

Komodo handles read-only files is a smart way, it opens file and shows a little lock on editor tab but user can edit the text buffer, it isn’t marked as read-only.

If user tries to save a warning message pops up allowing to choose if saving must be forced or cancelled.

Cool sure but I want to mark editor buffer as temporary read-only irrespective to file flag, this feature is missing on Komodo but scintilla has a readonly property.

I’ve added to MoreKomodo the ability to mark editor buffers as “edit locked”.

I think “edit locked” sounds good then “buffer read-only”.

The code is straightforward, simply sent the scintilla readonly property as shown below

     onToogleLockEdit : function() {
        var view = ko.views.manager.currentView;
        view.scintilla.scimoz.readOnly = !view.scintilla.scimoz.readOnly;
    }

RichScrollbar sunset

RichScrollbar extension, RSB for friends, is quite simple and not intrusive but technically is a big compromise.
It is written as  XBL component and runs inside chrome context and  browser content context.

Under Firefox 3 beta1 and beta2 RSB after some fix worked like a charm, when beta3 arrived RSB was broken.

Mark Finkle helped me to understand why RSB didn’t work and we discover FF3 fixed a security bug on XBL.

Now it is impossible to make RSB functional on browser windows, it works only on chrome dialogs.

I surrend, period! I have not enough technical knowledge to dig for a workaround.

I consider terminated the RSB development, the XBL documentation is poor and all my help requests haven’t received reply except Mark.

Honestly I’m sad, I love RSB and I prefer it to Mouse Gestures, I’ll continue to search for a fix but it is very difficult to find.

Mark helped me and I would say thank to him, great people work at Mozilla.

Richscrollbar released

After ten months I’ve released a new Richscrollbar (RSB) version, starting from FF3 compatibility issues I’ve done some other work.

Finally standard OS themes aren’t offended by old ugly RSB scrollbars, now RSB integrates better with the native OS look&feel.

Now RSB simplifies integration with themes, a model based on supported themes repository allow me to quickly add css styles.

Finally users can decide to remove RSB scrollbars from listbox, tree and so on and have them only on main browser window.

Very strange is the reason RSB doesn’t work on FF3; The nsIStyleSheetService.USER_SHEET must be changed to nsIStyleSheetService.AGENT_SHEET

It’s always present the problem with disabled javascript due to bug 236839 that limits RSB usage for example with Thunderbird or when NoScript is installed

Initially I would make RSB compatible with Seamonkey but the current number of users is so little that this compatibility isn’t necessary