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)
<toolbarbutton id=“viewsourcewith-button” insertafter=“stop-button”/>
and composeToolbar for mail composition window
<toolbarbutton id=“viewsourcewith-button” insertafter=“button-attach” />
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)
<preference id=“browser.toolbars.showbutton.viewsourcewith” name=“browser.toolbars.showbutton.viewsourcewith” type=“bool”/>
and declare its usage into checkbox element
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 😉