Snippets code from my daily experience

January 4, 2010

VisualDiffer 1.2 beta 1

I spent the Christmas holidays working on VisualDiffer, the Komodo visual folders/files comparison extension.

Now I want to migrate VisualDiffer from extension to standalone application using XULRunner because the folders comparison feature is mature and using it from an extension can be a bit complicated.

The migration requires some intermediate steps

  • Remove dependencies from Komodo code (especially the unified diff algorithm)
  • Remove dependencies from unified diff algorithm!!
  • Complete the file comparison feature allowing in-place editing using Bespin.
    Bespin can greatly simplify syntax highlight for different languages, search in file and so on
    Honestly I’m considering also to stay with Scintilla (actually used by Komodo) but I love Bespin
  • Use a cool graphic layout, especially toolbar icons
    I’m not a GIMP guru so if somebody would to help me he/she would be welcomed 🙂
  • Allow user defined fonts and colors (low priority task)

I hope to release the VisualDiffer V1.2 for Komodo in a couple of weeks but also not Komodo aficionados can take a look to it installing the beta version on Firefox 3.5.x (also 3.6b5) and SeaMonkey 2.x.

Under Firefox and SeaMonkey the “files differ” feature isn’t implemented (Komodo dependencies) but you can test the folders differ feature that is totally based on standard Gecko interfaces, you can find the VisualDiffer item under the Tools menu.

Obviously VisualDiffer on Firefox is a nonsense because it isn’t a browser oriented extension I distribute this version with Firefox support with the hope a larger community can try it and give me feedback before I jump on the XULRunner world.

The V1.2 beta 1 can be downloaded from here.

VisualDiffer is inspired by the fantastic Beyond Compare but this isn’t a mystery 😉

July 18, 2009

Discontinue extensions support for some applications

Filed under: extension,firefox,flock,komodo,kompozer,seamonkey — dafi @ 4:46 pm

Before publish new updates for my extensions I try to test them on every application declared supported on install.rdf, this is a very expensive activity when a specific extension runs on different kind of applications and versions.

I add support for a new application (e.g browser, email client, multimedia applet)

  • when I use the application itself and I need the extension functionality on it
  • when other users ask to me

Now I must decide to drop support for some applications and for specific versions to simplify my release tests cycle.

In some cases it’s easy to decide, for example Firefox 2.x is no longer supported by Mozilla and users continuing to use it are braves or simply fools.

Supporting SeaMonkey 1.x is very hard for me, no special technical problems SM is a very good product but I simply don’t use it.
Instead I’m a satisfied SeaMonkey 2.0 user since alpha1 version.

Supporting Flock, the “social” browser, is easy due to the fact is very compatible with Firefox 3.x but sometimes little differences caused me headaches.
I think to drop support for extensions not Flock centric considering the decision taken from its team last December

Komodo 4.x is no longer upgraded by ActiveState but many people continues to use it, Komodo has a commercial version, KomodoIDE, and not all users purchased the upgrade (me too) so it is very difficult to drop the very old 4.x architecture.

NVU is dead but many users continue to use it also if its sibling/son Kompozer should be strong preferred.

What specifically means “discontinue support”

I would to remove specific tricky code present in extensions to make them cleaner but this can be a bad solution, regressions are always possible so the cure can be worse than the disease…

Removing SeaMonkey 1.x support will make my extension build system cleaner no longer install.js, contents.rdf  and informations present both in install.rdf and chrome.manifest, obviously I don’t discard support only to remove a couple of configuration files but I consider it another complication.

So, “discontinue support” for me means moving attention and energies on applications (and versions) I can test easily, on application I daily use, on applications I receive feedback from other users.

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 😯

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 😉

Create a free website or blog at WordPress.com.