Snippets code from my daily experience

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😉

7 Comments

  1. It annoys me that each application uses different IDs on its menupopups, so I have to create separate overlays for every application my extensions are compatible with.

    Comment by Minh Nguyễn — October 15, 2008 @ 9:30 pm

  2. Hi SeaMonkey developer here.

    These are wrong. They should be:

    Currently the SeaMonkey 2.0 code to show/hide buttons is still the same as SeaMonkey 1.1 As is the preferences UI. The underlying implementation has changed to use the toolkit code.

    Currently I am working on a couple of bugs to port the Firefox customize toolbar code to SeaMonkey and we hope that when SeaMonkey 2.0 final is out you can reuse more of your firefox overlays and code.

    You are also welcome to ask us any questions on irc://moznet in #seamonkey and in news://mozilla.dev.seamonkey

    Phil

    Comment by Philip Chee — October 16, 2008 @ 4:13 pm

  3. Your comment box ate some angled brackets.

    “The underlying options implementation has changed to use the toolkit prefwindow code although our pref-window UI remains the same.

    Phil

    Comment by Philip Chee — October 16, 2008 @ 4:15 pm

  4. Re: comment #1

    When Blake Ross forked the browser code from the Suite to make Firefox he gratuitously changed element IDs and file names and shuffled things around, and *now* extension authors blame the SeaMonkey Suite for “using different IDs” when it’s the other way around!

    At least the Thunderbird developers were sensible enough to keep the same file names and (mostly) the same element IDs when they forked the mailnews code so things are much more compatible from a Thunderbird extension developers point of view.

    Phil

    Comment by Philip Chee — October 16, 2008 @ 4:19 pm

  5. p.s. Please change “hbox” and “toolbarpalette” in your code to “toolbar”

    Thanks.

    Phil

    Comment by Philip Chee — October 16, 2008 @ 4:21 pm

  6. Hi Phil, thanks for tips about “hbox”.
    Consider my extensions aren’t so popular, should be better for me to make them compatible only for Firefox but I continue to support SeaMonkey because I love it. When I installed VSW on SM2.0a1 discovering it didn’t work correctly I was a bit astonished.
    Maybe my initial SM integration was wrong but I think also the behavior has changed not only the underlying implementation.

    Thanks for your feedback, consider I’ve written this post because I want to make always better SM support.

    Comment by dafi — October 16, 2008 @ 4:30 pm

  7. “I can’t understand why SeaMonkey, especially the 2.0 version, doesn’t adopt the same Firefox elements.”

    Because the Firefox toolbar customisation code is a mess, and I didn’t want to touch it with a 10′ pole.

    I’ve submitted and revised patches to improve the situation to a point where I consider the code usable, but the review process is not fast.

    Comment by Neil Rashbrook (SeaMonkey UI Tsar/Czar) — October 17, 2008 @ 10:47 am


RSS feed for comments on this post.

Create a free website or blog at WordPress.com.

%d bloggers like this: