Error console in Komodo

I’ve need to migrate to Komodo a bunch of Firefox extension code logging using nsIConsoleService.

The output goes to error console but Komodo doesn’t directly allow to open it, you can manually execute the code shown below as a macro.

window.openDialog(‘chrome://global/content/console.xul’, ‘_blank’);

Any time the code is executed a new error console window is open, if you don’t like this behaviour past the macro shown below

function toOpenWindowByType(inType, uri, features)
{
var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1'].getService();
var windowManagerInterface = windowManager.QueryInterface(Components.interfaces.nsIWindowMediator);
var topWindow = windowManagerInterface.getMostRecentWindow(inType);

if (topWindow)
topWindow.focus();
else if (features)
window.open(uri, “_blank”, features);
else
window.open(uri, “_blank”, “chrome,extrachrome,menubar,resizable,scrollbars,status,toolbar”);
}

toOpenWindowByType(“global:console”, “chrome://global/content/console.xul”)

Alea iacta est: OpenKomodo localized

Alea iacta est the first OpenKomodo lang pack has landed.

I’ve already spoken about KomodoEdit localization and now the french Babelzilla team has terminated the first version, the official announcement has posted at Mozilla Europe site.

I’m very happy, I’ve developed macros to simplify lang pack testing and created a simple webapp to convert babelzilla locale tarballs to installable xpi langpacks.

Maybe ActiveState guys hate me because the translation idea started from me, but I believe localized (and open) softwares are simpler to use in schools, poor information environments and any low profile educational eco-systems.

The italian lang pack is coming soon, I will be very proud to use KomodoEdit in my mother tongue.

I hope other localizations can arrive very soon

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>

Determine if the current view is a macro in Komodo

Komodo allows to edit macros in editor windows, this feature simplifies the macro code writing.

Do you need to know if you are editing a macro? Well You must fight with koIPart interface.

After digging into Komodo IDLs I found a way to know if current view is a macro, take a look at code shown below.

var currView = ko.views.manager.currentView;
var fileURL = currView.document.file.URI;
var macroPart = ko.toolboxes.user.toolbox.getChildByURL(fileURL);
var isMacro = macroPart != null && macroPart.type == “macro”;

I’ve asked at irc.mozilla.org#komodo channel and mixedpuppy confirmed me this is the best way.

Komodo wiki content

I continue to add content to official Komodo wiki page.

I’m not sure ActiveState is boring to read my contributions but I think a centralized place is better than my blog.

The last added page topic treats the Komodo Notifications, a powerful mechanism to be informed about editor activity.

Only the most important notifications are listed but I hope to complete the list

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;
    }