The Wayback Machine - https://web.archive.org/web/20081218200819/http://dafizilla.wordpress.com:80/

Snippets code from my daily experience

December 13, 2008

Komodo French Localization coming soon

Filed under: babelzilla, komodo, localization — dafi @ 10:56 am

This morning I’ve found a couple of emails coming from my BabelZilla forum subscriptions, after reading them I went to WTS homepage where I saw the image shown below.

komodo-locale

Fantastic! The French localization is completed, 2016 strings translated!

When I asked to BabelZilla guys to localize Komodo I could not imagine they did it so quickly.

Many activities must be coordinated with ActiveState team

  • Remove all hardcoded strings (amazingly new code continues to be written with hard-coded strings!!! 8O :???: )
  • Establish a time deadline to froze new strings added to trunks (this can drastically simplify localization cycle)
  • Lang Pack release process and better integration with code development lifecycle

But be calm dafi :P … one step at a time

I want to say thanks to Goofy, the BabelZilla Super Mod, and Pedro the Italian localizer that helped me from the beginning, they helped me to “extract” hard-coded strings and prepare patches to submit.
A big “thank you” goes to all localizers (especially the French community) for dedicating time and passion to this work.

Technically speaking an installable French lang pack is already ready for KomodoEdit v5.0.2, French team are completing the quality test and everybody can help them.

Who want to see Komodo in French can register on Babelzilla and read more at Komodo Lang Pack forum thread…

… and Goofy has already localized in French my extension TabSwitcher

November 21, 2008

Komodo ViewAbout

Filed under: extension, komodo, mozilla, openkomodo, xul — dafi @ 7:42 pm

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 :D

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)

aboutview


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

November 8, 2008

Four years of ViewSourceWith: Version 0.4 released

Filed under: nsIProcess, viewsourcewith — dafi @ 11:49 am

Today I’ve released VSW 0.4, this version mainly contains bug fixes but it is the first version using the IWinProcess the nsIProcess component replacement.
I hope people using non latin charset can appreciate this little improvement.

I’ve also added SeaMonkey 2.0a1 support, this required me some time but SM2 is very cool and can’t be ignored.

Since November 2004 when VSW 0.0.1 was published many other similar extensions have been created and those extensions today are very cool and maybe VSW has arrived to the end, I’m not sure its development is still useful for the developer community.

The only feature a never seen in other extensions is the ability to edit richbox text like Gmail content messages or WordPress HTML posts but probably I missed the extensions doing it ;)

November 7, 2008

Java plugin with Prism under Ubuntu 64 bit

Filed under: 64bit, java plugin, linux, prism, ubuntu — dafi @ 8:54 pm

This post in mainly for my own usage, my brain loose very quickly informations :P

I use Ubuntu Intrepid Ibex 64bit version with Firefox Linux x86_64 and occasionally I need to visit some website using Java applets, as well known to run Java plugin you need to use the Firefox 32bit version because the Java plugin exists only for this architecture.

I don’t want to trash my FF 64bit (also Swiftweasel) only for Java plugin so I’ve decided to configure Prism to use the websites needing java plugin.

  • Install the 32bit version of java
    sudo apt-get install ia32-sun-java6-bin
  • Create a symlink to plugin
    sudo ln -s /usr/lib/jvm/ia32-java-6-sun/jre/plugin/i386/ns7/libjavaplugin_oji.so \
    /home/dave/.mozilla/plugins/
  • Create a prism webapp, for example using the Sun test page

The destination path /home/dave/.mozilla/plugins/ must be modified according to your settings

This confirms Prism is rock ;)

November 4, 2008

Komodo 5 released

Filed under: komodo — dafi @ 7:37 pm

The day has come, Komodo Edit 5 and its big brother Komodo IDE 5 have been released.

You can read complete feature list here, I want to speak about some technical aspects.

  • Komodo is the best text editor using Mozilla technologies now based on Firefox 3 (i.e. gecko 1.9)
  • Now the old mono-window notification-based mechanism is no more supported (read here) because multi windows works greatly
  • Simplified many document operation (read here)
  • Many cool extensions already compatible with 5.0 (read here)
  • Many Firefox extensions works like a charm (I love DOM Inspector*)
  • New APIs for extension developers

I’ve some problems to run it under Linux (also Ubuntu 8.10) because crashes but ko5 is amazing.

I’ve updated the wiki adding “View Events” but I want to change radically approach, something like MDC where APIs are well documented.

Documenting API is a very complex work but I will try ASAP ;)

* Running DOM Inspector can require the following macro
window.openDialog(”chrome://inspector/content/”, “_blank”, “chrome,all,dialog=no”);

October 27, 2008

Simplify Mozilla profiles usage

Filed under: bash, cygwin, firefox, flock, komodo, mozilla, openkomodo, songbird — dafi @ 3:00 pm

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

October 20, 2008

Adding Komodo macros to context menu

Filed under: context menu, komodo, macro, onpopupshowing, xul — dafi @ 6:37 pm

Komodo macros allow to add new features to the editor, they are like little XUL extensions embedded into application.

I’ve written dozen of macros and many of them are strictly related to cursor position or selected text so it sounds reasonable to access them using the context menu but at this time Komodo doesn’t allow this.

Adding macros to context menu is easy, it can be done also using a ‘Trojan’ macro :D triggered at Komodo startup but the best results are achieved using an extension containing configuration dialogs and other whistle and bells.

I’m lazy so I use one mega wrapper extension where I put any new code, a very quick and dirty practice.

Here I want to share the snippets necessary to add macros to context menu and running them selecting the corresponding menuitem.

For the sake of example the code shown below adds all macros found on toolbox, this can produce a very long (and unusable) menu.

It is necessary to install the onpopupshowing event handler so we can add/remove menu items dynamically.


onLoad : function() {
    var ctx = document.getElementById("editorContextMenu");
    ctx.addEventListener("popupshowing", this.onPopupShowing, false);
}

the onPopupShowing function accesses to toolbox and populates the context menu


onPopupShowing : function(event) {
    var arr = {};
    var count = {};

    // get all macros, very ugly but easy to customize
    ko.toolboxes.user.toolbox.getChildrenByType("macro", true, arr, count);

    // remove menu items
    var i = 0;
    var mi;
    for (var i = 0; mi = document.getElementById("macro2ctx" + i); i++) {
        mi.parentNode.removeChild(mi);
    }

    var ctx = document.getElementById("editorContextMenu");
    for (var i = 0; i < count.value; i++) {
        var mi = document.createElement("menuitem");
        var file = arr.value[i].getFile();
        mi.setAttribute("id", "macro2ctx" + i);
        mi.setAttribute("label", file.leafName);
        mi.setAttribute("oncommand", "macro2Ctx.onRunMacro('" + file.displayPath + "')");
        ctx.appendChild(mi);
    }
}

Finally the onRunMacro function executes the macro found starting from its URL

onRunMacro : function(url) {
var item = ko.toolboxes.user.toolbox.getChildByURL(url);
ko.projects.executeMacro(item);
}

That’s all Folks

I hope to move all code on a separated extension and publish it…

but before

  • Macros to add to context menu must be choosen by user
  • Macros must be removed easily
  • Choose the context menu to use (tab context menu or editor context menu)
  • Allow to show macro only if it matches some criteria (like isCommandEnabled)
  • Better error handling

October 16, 2008

Release Early and Release Often: MoreKomodo 1.4.3

Filed under: Uncategorized — dafi @ 6:19 pm

Published MoreKomodo 1.4.3.

Now it is possible to access favorites from Remote File Dialog

Favorite and Remote Files

Favorite and Remote Files

More details are available at MoreKomodo website.

October 15, 2008

SeaMonkey 2.0a1 and the mistery of the disappeared toolbar button

Filed under: extension, seamonkey — dafi @ 8:33 pm

I’m preparing the new ViewSourceWith release so I’ve decided to test it under the alpha version of SeaMonkey.

The SeaMonkey two dot zero is a little revolution (at least for me) because it’s based on Gecko 1.9 and is closer to Firefox, finally it uses the standard extension manager and many other benefits for extension authors.

After tweaking maxVer and installed VSW I noticed the VSW toolbar button is missing, trying to enable it from “Navigation Toolbar” Preferences dialog produced no result :(

A regression? A new container id to use?

After some frustrating hours I discovered SM2.0a1 doesn’t handle toolbar buttons like Firefox 2.x/3.x and amazingly it doesn’t work like SM 1.1.x 8O

Restoring VSW toolbar button required the following modifications

The overlay uses nav-bar id for browser toolbar button (svn code)

<hbox id=“nav-bar”>
<toolbarbutton id=“viewsourcewith-button” insertafter=“stop-button”/>
</hbox>

and composeToolbar for mail composition window

<toolbarpalette id=“composeToolbar”>
<toolbarbutton id=“viewsourcewith-button” insertafter=“button-attach” />
</toolbarpalette>

This is sufficient to finally show the icon but to allow user to decide to hide/show button you must handle the navigator_preferences inside pref-navigator.xul’s overlay (svn code)

<preferences id=“navigator_preferences”>
<preference id=“browser.toolbars.showbutton.viewsourcewith” name=“browser.toolbars.showbutton.viewsourcewith” type=“bool”/>
</preferences>

and declare its usage into checkbox element

<groupbox id=“prefShowButtonsBox1″>
<vbox>
<checkbox id=“viewsourcewithButton”
label=“ViewSourceWith”
preference=“browser.toolbars.showbutton.viewsourcewith”/>
</vbox>
</groupbox>

and finally they lived happily ever after…

The question is… Why is it so difficult to standardize the toolbar handling within XUL applications?

At least Komodo, SeaMonkey and Firefox use different ids and overlays (Flock and Songbird are more closed to Firefox).

I can figure out Firefox is a browser and Komodo is an editor with different application requirements but I can’t understand why SeaMonkey, especially the 2.0 version, doesn’t adopt the same Firefox elements.

Maybe the final 2.0 will simplify more the extension developer’s life also for handling toolbar button.

BTW SeaMonkey2 is very cool ;)

October 13, 2008

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

Filed under: extension, komodo, openkomodo — dafi @ 3:14 pm

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 8O

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)

Next Page »

Blog at WordPress.com.