After reading ViewAbout post written by Gary Kwong I was curious to see what Komodo should have shown.

Komodo doesn’t require to write an extension to implement a similar feature, it is sufficient to write a macro

So I’ve written the code that adds a popup menu inside Help menu and amazing it worked immediately

The macro can be triggered at startup but the menu will be added only on first open window because Komodo doesn’t have a “on open new window” macro event but it can be easily simulated adding a listener.

The code shown below is the complete Komodo Javascript macro, nothing else is necessary. (EDIT Thanks to Mook to point me how to remove the hardcoded abouts list)

var abouts = [];
for (var c in Components.classes) {
    var m = c.split(/=/);
    if (m[0] == "@mozilla.org/network/protocol/about;1?what") {
        if (m[1]) {
            abouts.push(m[1]);
        }
    }
}

var menuAbouts = document.createElement("menu");
menuAbouts.setAttribute("label", "All abouts:");

var menuAboutsPopup = document.createElement("menupopup");
menuAbouts.appendChild(menuAboutsPopup);

var helpMenuSeparator = document.getElementById("menu_helpShowKeybindings").nextSibling;
var helpMenu = helpMenuSeparator.parentNode;
helpMenu.insertBefore(menuAbouts, helpMenuSeparator);

for (i in abouts) {
    var menuitem = document.createElement("menuitem");
    menuitem.id = abouts[i];
    menuitem.openAbout = openAbout;
    menuitem.setAttribute("label", abouts[i]);
    menuitem.setAttribute("oncommand", "this.openAbout('" + abouts[i] + "')");
    menuAboutsPopup.appendChild(menuitem);
}

function openAbout(about) {
    var docSvc = Components.classes['@activestate.com/koDocumentService;1']
                    .getService(Components.interfaces.koIDocumentService);
    var doc = docSvc.createDocumentFromURI("about:" + about);
    ko.views.manager.topView.createViewFromDocument(doc, "browser");
}

I use many applications written using Mozilla technologies, these applications support the so called profiles allowing users to run multiple instances of same application but using different “configuration” environments.

As developer I use profiles to test extensions without compromise the integrity of my main env.

Running multiple profiles is described in million of places so I don’t annoy you but I describe my own solution based on a bash script that hides details.

Creating bash scripts to run separated application profiles requires only a bit of shell programming experience but it is a repetitive task and can be boring when you need to run different version for example firefox 2 and firefox 3, you manually must write the same script modifing only the application path.

My approach allow to configure applications to run in a single file and then create automatically the necessary scripts.

Suppose you want to run a new songbird profile, using my script you can write:

dave@dafihome:~$ sb

The sb script creates a new separated profile on a configured directory with a default name, but suppose you need a second (third and so on) songbird profile you can pass your preferred name

dave@dafihome:~$ sb testVSW

Now you need to test also Firefox 2.x and Firefox 3.x profiles, simply write

dave@dafihome:~$ ff20 testVSW
dave@dafihome:~$ ff30 testVSW

So you have three separated profiles with same name testVSW, how they don’t clash? The real name created by script uses the application prefix so the directories names are

• sbtestVSW
• ff20testVSW
• ff30testVSW

Do you need Komodo 4.4.x and 5.x profiles? Again

dave@dafihome:~$ ko4
dave@dafihome:~$ ko5 italian-locale

Configuring applications

The names sb, ff20, ff30, ko4 and ko5 are configured in ‘~/.moz_profilerc’

The file format is very similar to fstab and contains three columns describing applications.

The first column contains the type of application.

At this time it can be set to mozapp or komodo, this is necessary because mozilla apps uses MOZ_NO_REMOTE env variable to run separated profiles instead komodo uses KOMODO_USERDATADIR.

The second column is the script name user runs from command line (and is also the prefix added to profile directory names)

The third column contains the application absolute path

Below is shown my configuration

mozapp     ff30          /opt/devel/mozilla/ff30/firefox
mozapp     ff30en        /opt/devel/mozilla/ff30en/firefox
# ff20 refers to installed firefox
mozapp     ff20          /usr/bin/firefox

mozapp     flock         /opt/devel/mozilla/flock/flock

mozapp     komp          /opt/devel/mozilla/kompozer/kompozer

mozapp     sb            /opt/devel/mozilla/Songbird/songbird
mozapp     mccoy         /opt/devel/mozilla/mccoy/mccoy

komodo     ko5           /opt/devel/mozilla/ko5/bin/komodo
komodo     ko4           /opt/devel/mozilla/Komodo-Edit-4/bin/komodo

Profile destination directories

I group profiles by extension, for example inside ViewSourceWith source directory I have a ‘profile’ subdirectory where all profiles are written, this is specified in ‘~/.moz_profilerc’

# Directory where profiles will be created, inside profile present on current directory
profileDir      $PWD/profile

# If true create profileDir silently, otherwise generate error
profileDirCreateSilently    false

It is possible to write all profiles inside a specific directory setting profileDir

profileDir      /devel/mozapp/profiles

Scripts destination directories

The scripts sb, ff20, ff30, ko4, ko5 are symbolic links, they are generally created inside a directory present on $PATH env variable.

I prefer to add them inside /usr/local/bin (this should require to be root)

# Directory where links will be created, generally resides in env PATH
linkDestDir     /usr/local/bin

The script moz_profile.sh

All operations are done using the script moz_profile.sh that allows to edit configuration file and create applications scripts.

Editing configuration (it opens the editor set on $VISUAL or $EDITOR env)

dave@dafihome:~$ moz_profile.sh -e

Creating scripts

dave@dafihome:~$ moz_profile.sh -c

This script greatly simplifies switching from profiles, obviously occupied disk space grows but after a profile is no more needed you can delete it without risks

The script, that works also on Cygwin, is present on SVN repo at moz_profile.sh

I’ve written a little XPCOM component that worked immediately thanks to the good tutorial written by Mark Finkle.

The extension stopped to work when I’ve installed it on computer different from my development environment, the error in console was

Failed to load XPCOM component: c:\Documents and Settings\…

The solution was to statically link the C/C++ runtime and add msvcrt to nodefaultlib switch.

VC++ Express 2008 (or above??) users must set from Configuration Properties

• C/C++ -> Code Generation -> Runtime Library = Multi-threaded (/MT)
• Linker -> Input -> Ignore Specific Library = MSVCRT.LIB

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

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

I wrote a little XBL component to allow menuitems to have images centered, I added it to Firefox 2 browser context menu and worked fine immediately, after a while I installed component on Firefox 3 beta 4 and surprisingly the menuitem didn’t show the image

I’ve asked help on Mozilla IRC and after about an hour the mistery was revealed.

The innocent CSS declaration shown below works fine on Firefox 2

.menuitem-image-center {
-moz-binding: url(‘chrome://morekomodo/content/bindings/menu.xml#menuitemImageCenterBinding’);
}

but requires a little modification on Firefox 3 beta 5pre (at this time the latest available)

.menuitem-image-center {
-moz-binding: url(‘chrome://morekomodo/content/bindings/menu.xml#menuitemImageCenterBinding’)
!important;
}

You must notice the selector without !important attribute works on Firefox 3 when applied on menus different from browser context menu.

I suspect the browser context menu should have some special treatment on new Firefox…

January and February are very important months for my programming activites.

In January ActiveState guys gave me a KomodoIDE license for my contribution to their OpenKomodo wiki, a great unexpected surprise, the first one.

A couple of days ago Mozilla published the Extend Firefox 2 Contest and I discovered my name on “Runners up” list, a great
unexpected surprise, the second one.
I can figure out ViewSourceWith is the winner, no! The winner is Table2Clipboard my outsider extension, a great unexpected surprise, the third one.

I’m happy that other people appreciates my work.

My feed reader alerts me, LifeHacker has new contents, I take a look and found they speak about Table2Clipboard, a great unexpected surprise, the fourth one.

ActivateState gave me a KomodoIDE license, EF2 prices contain a KomodoIDE license, now I have two KomodoIDE license, another surprise the fifth

Mumble mumble… may I sell the unused license?

When I started Richscrollbar (RSB for friends) development I could not figure out a so difficult programming life cycle.

After all its task is simple, add extra buttons to browser scrollbars to speedup movements inside web page.

Gecko is affect by a bug that reduces RSB productivity dramatically but I’ve created it anyway.

Now I discover RSB totally doesn’t work with Firefox 3 beta 2, Mozilla guys changed API and I suspect introduced some regression.

Obviously it is impossibile to explain the problem to Mozilla, they are so busy to fight against the world.

After some frustrating debug I found the problems and fixed them.

Problem nr 1.

The nsIStyleSheetService.USER_AGENT has changed behaviour without documenting it (at least at this date)

I used USER_SHEET in Firefox 2 but under FF3 the same code simply doesn’t work.

I’ve replaced it with the other flag AGENT_SHEET and magically RSB started to work.

Where can I read the new behaviour? Damned Mozilla

Problem nr 2.

An horizontal useless scrollbar is always visible only on tab window open at browser startup, if user opens new tab and/or windows this dumb doesn’t appear, sigh!

I found a reasonable workaround hiding the scrollbar inside the notificationbox component.

I hope to publish the fixed RSB on this weekend.

Firefox 3 will introduce a new mechanism to ensure update urls are safe.

Every update url used into extension’s manifest must use httpS certified sites.

Due to the fact not all developers can buy certificate or use httpS site a second mechanism allows to sign extension and server update file.

I host my extensions on Sourceforge but Sourceforge doens’t support https so I decided to sign extensions.

Mozilla guys had created McCoy an useful UI from which you can generate public keys and sign files.

McCoy UI doesn’t fit my automated xpi creation process, I prefer a command line approach

Well, Star Trek’s Dr. McCoy has a good friend, the vulcanian Mr. Spock

From the genius of bard, the Sameplace.cc’s author, borns Spock the McCoy command line missing piece.

Now you can create public keys from cool McCoy UI and complete process from command line with Spock.

Read more at hyperstruct

Finally Komodo is open!

More informations at http://www.openkomodo.com/

Komodo isn’t a promise it is reality.

Open source === Open minds

Why I love it?

I use shanec words

#It allows you to work the way you want to

Sure, you don’t need to fit to your editor but your editor fits to you.

#It’s built for developers by developers

I’ve used ActivePerl for years a step ahead over perl language, a tool designed by programmers with my same needs

Now OpenKomodo is the new frontier, the missing piece: THE EDITOR.

D2D is the right definition: Developer2Developer

# It’s easily extensible using XML, JavaScript, and if you like, Python, and C++

Ok OpenKomodo isn’t perfect for my needs but I can reuse my skills to enhance my programming experience

Use well know technologies to plug new behaviours, I love XUL and you?

The big problems with OpenKomodo are startup-speed and memory usage but these problems are related to Jecko runtime not to ActiveState’s guys implementation.

Do you think I’m a ActiveState employee? No! I’m a programmer that finally founds his programming home.