Colored file tabs for Komodo

A couple of months ago I wrote a Komodo macro allowing the editor view tabs to be colored based on user defined color schemes, when the macro became stable I published it on Komodo community forum.

Amazingly the macro received more feedback so I decided to ‘convert’ it to an XUL extension.

Komodo macros are fantastic but they don’t allow to create complex UIs so moving them to XPI become a necessary step.

Now ColorTab is ready and can be downloaded from here.

The original name was KolorTab, the ‘K’ letter used to remember Komodo but I’ve decided to use a more tradictional name 😛

ColorTab look&feel

Komodo maintenant parle Français (Komodo now speaks French)

The Babelzilla Team is proud to present the (unofficial) Komodo French localization.

Komodo 5.1 has been released, it contains many cool features and the Babelzilla guys have completed the FIRST localization, the first one.

You can find further details at French Mozilla blog and the installation instructions at BabelWiki

A special thanks goes to Goofy that coordinated the L10N work.

Thanks guys, you made the world a better place without linguistic barrier.

Adding CSS Color Preview Tooltip to Komodo

Do you know Firebug? Uh no? Well please make a jump in twentieth century then return here 😛

Firebug has many great features but I love the color preview tooltip, from CSS Tab moving the mouse over a CSS color expression you will see a little box filled with the color found under the mouse pointer.

Every time I edit CSS (and HTML) files from Komodo subconsciously I move mouse over a color waiting to see the tooltip but nothing happens 😦

I’ve realized a macro can do this job so I’ve written ColorInfoTip that adds to Komodo the ability to show colored tooltip.

Some technical detail

This is a macro! No need to create extensions, the Komodo macro ecosystem is very cool and powerful.

The tooltip is a scintilla Call tip accessible from Komodo API.

The CSS color string can be written using many syntaxes like #RRGGBB or rgb(R,G,B) instead of reinventing the wheel and write the parser I’ve used the getRGBColorValue standard DOM method.

I discovered Scintilla uses BBGGRR color format instead of RRGGBB so the CSSRGBColor components have been converted to be Scintilla compliant.

Known problems

The macro isn’t perfect and any help is welcomed

• Sometimes the tooltip doesn’t close especially changing editor view
• Moving mouse quickly doesn’t update the color (fixed)
• fill here the bug you found

ColorInfoTip.kpz

You can download the macro from ColorInfoTip.kpz then open the file from Komodo to install

Komodo ViewAbout

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");

}

Simplify Mozilla profiles usage

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

Komodo 5: how to detect when a document is attached to an existing view

Komodo 5 in under construction but developers can start to appreciate the new features working with alphas and SVN sources…

Another weapon is available to Komodo extension developer, version 5 make easier to be informed when the document attached to a view changes.

A couple of new events (remember notifications are no more supported for view operations) are finally available

• view_document_attached
• view_document_detaching

Both events put into event.originalTarget the view involved and the view.document object is never null.

Obviously can be null the view.document.file property, for example when user chooses File|New File… from menu.

The code shown below creates a new document and attaches it to the current view, developer doesn’t need to notify using its own code but it is sufficient to listen the standard view_document_attached

var uri = "..";

var newDoc = Components

    .classes["@activestate.com/koDocumentService;1"]

    .getService(Components.interfaces.koIDocumentService)

    .createDocumentFromURI(uri);



newDoc.load();



// At this time Komodo 5 fires the view_document_attached event

ko.views.manager.currentView.document = newDoc;

view_opened bug fix

The well known 4.4.x notification/event view_opened has been fixed on Komodo 5 to have the document property correctly set.

Prior Komodo 5 the view sent during notification had (amazingly!) the document set to null 😯

The view_opened and view_document_attached are strictly related, when a file is opened the view receives both events.

Klint will use view_document_attached to disable syntax checking based on file path regular expressions (eg disable syntax checker for all “.*log” files)

Migrating Komodo 4.x to Komodo 5.x

ActiveState has released Komodo 5.0.0 alpha 1 with many exciting enhancements.

The new features, for example the multi-window, have impact on existing code that requires modifications to continue to work.

The new model based on DOM events instead of global notifications requires only few lines of new code.

All notifications changed in events are shown below, remember they are no more usable as notifications!

• codeintel_activated_window
• codeintel_deactivated_window
• current_view_changed
• current_view_check_status
• current_view_encoding_changed
• current_view_language_changed
• current_view_linecol_changed
• view_closed
• view_list_closed
• view_opened

How to write new code

New code must be written using the window.addEventListener method, well known by Firefox (or Thunderbird) extensions developers.

Event handlers

The addEventListener method requires as parameter a callback function receiving the event object, the event’s originalTarget attribute contains (when applicable) the koIViews associated with event.

Removing listeners

When a window is closed every resource associated to it must be released so you must call the removeEventListener for every added listener.

The best place to remove listeners is inside the function associated to unload event.

Accessing to ‘this’ javascript object

When addEventListener is called from a prototyped object or simply from a namedspace method we must be sure the callback works with correct javascript ‘this’ object.

The Komodo code uses a well known approach; it declares a nested function and passes it to addEventListener

var moreKomodo = {
addListeners : function() {
var self = this;

this.handle_current_view_changed_setup = function(event) {
self.onCurrentViewChanged(event);
};

window.addEventListener(‘current_view_changed’,
this.handle_current_view_changed_setup, false);
},

_updateLockEdit : function(view) {
…
},
};

So the onCurrentViewChanged method can continue to work with the moreKomodo (this) instance

onCurrentViewChanged : function(event) {
var currView = event.originalTarget;

this._updateLockEdit(currView);
},

How to dispatch events

Should be necessary to dispatch events, for example MoreKomodo after renaming/moving a file requests to refresh title bar sending a current_view_changed.

Dispatching DOM events is easy but under Komodo developers can use the helper class domutils that contains the fireEvent utility method.

The xul file must contain the xtk inclusion

<script src=“chrome://xtk/content/xtk.js” type=“application/x-javascript;version=1.7”/>

Then the js file must contain the domutil inclusion

xtk.include(“domutils”);

Then you can call the fireEvent

if (typeof(xtk.domutils.fireEvent) != “undefined”) {
xtk.domutils.fireEvent(view, ‘current_view_changed’);
}

If you want to write code compatible with 4.4.x version you need to test the fireEvent existence as shown above

Benefits from Gecko 1.9

Komodo 5 uses the Firefox 3 Gecko version and this is immediately visibile, a faster startup but most important many bugs resolved.

The tooltip problem on MoreKomodo finally disappeared 🙂

I don’t know if related to Gecko 1.9 but finally the mouse scroll wheel works on file tab.

Conclusion

I like very much the new Komodo, developers should be hurted from these refactoring but they are simple and easy to do also on complex extensions.

I’ve made MoreKomodo, TabSwitcher and Klint compatible in about two hours 😉

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

KomodoEdit localization

I’ve asked to babelzilla community if they are interested to translating KomodoEdit and immediately they reply to me that this is possible.

So I’ve posted into Komodo forum to understand if ActiveState is interested, too.

Well, all is ready and I’m glad to have started this process.

I don’t know what this experiment will produce but I’m happy to see collaborations between so different communities.

I hope to see very soon the first KomodoEdit in non english language 😛

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