[Ext] Console² 0.1 to 0.3.6.2

old zeniko · Post by **old zeniko** » January 19th, 2006, 10:47 am

@Peng: Right-click on the toolbar, select Customize and simply disable the icons (or select the small ones).

Peng · Post by **Peng** » January 19th, 2006, 1:20 pm

zeniko wrote:@Peng: Right-click on the toolbar, select Customize and simply disable the icons (or select the small ones).

Excuse me while I hit myself on the head for missing the obvious there. Thanks.

The adventure with CSS was still fun, though.

Eyal Rozenberg · Post by **Eyal Rozenberg** » January 20th, 2006, 2:31 am

Any chances for a seamonkey port anytime soon? :-(

(haven't I asked about this before? I wonder)

old zeniko · Post by **old zeniko** » January 20th, 2006, 7:58 am

Not before SeaMonkey is ported to Toolkit. There are simply too many little differences for me to make this happening (e.g. different toolbar customization, different sidebar format, different base listbox and worst of all different extension registration). And since the Toolkit port is already planned for SeaMonkey, that would mean investing time in a EOL'd platform. However if you find a SeaMonkey extension developer who'd write the necessary patches, you'll get a blessed release (porting still shouldn't be too difficult - if you include install.js and some context.rdf files, it mostly works already).

Philip Chee · Post by **Philip Chee** » January 20th, 2006, 10:28 am

zeniko wrote:Not before SeaMonkey is ported to Toolkit. There are simply too many little differences for me to make this happening (e.g. different toolbar customization, different sidebar format, different base listbox and worst of all different extension registration). And since the Toolkit port is already planned for SeaMonkey, that would mean investing time in a EOL'd platform. However if you find a SeaMonkey extension developer who'd write the necessary patches, you'll get a blessed release (porting still shouldn't be too difficult - if you include install.js and some context.rdf files, it mostly works already).

Works in the Sidebar did you say? I've just spent the last couple of weeks porting Firefox sidebar extensions to work in Seamonkey and they can be found here: http://xsidebar.mozdev.org/modified.html.

These are part of the xSidebar for Seamonkey project which ports the Firefox sidebar API/format to Seamonkey as an extension.

If you look here: http://downloads.mozdev.org/xsidebar/mods/ there is a install-template.js which you can use to modify. Rename it to install.js and put it into the root of the .XPI file. That should get you started.

Phil

old zeniko · Post by **old zeniko** » January 20th, 2006, 2:14 pm

Yes, that might alleviate the sidebar thing. However, the toolbar differences are considerably more striking, the listbox differences annoying and the missing of chrome.manifest and on-the-spot registration kills my motivation.

BTW: Wouldn't it make sense to have the install.js look for the existence of xSidebar and automatically install it if needed?

Philip Chee · Post by **Philip Chee** » January 20th, 2006, 6:45 pm

zeniko wrote:However, the toolbar differences are considerably more striking, the listbox differences annoying and the missing of chrome.manifest and on-the-spot registration kills my motivation.

Yes I do wish that the aviary toolbars were checked in. Can the current patch be checked in without the aviary toolkit being landed?

What do you mean "on-the-spot registration"? In my compile/test cycle I discovered that Seamonkey extensions are immediately active without having to restart; I do need to open a new window to see the changes though - but it's still faster than having to shutdown.

zeniko wrote:BTW: Wouldn't it make sense to have the install.js look for the existence of xSidebar and automatically install it if needed?

I'm not too sure what you mean. xSidebar is an extension. Without it the Firefox sidebar hooks aren't available in Seamonkey. I hope that if the Seamonkey sidebar module owner likes it enough that this may make it into Seamonkey 1.5. Unfortunately the current situation is "don't call us we'll call you."

Phil

Philip Chee · Post by **Philip Chee** » January 20th, 2006, 6:50 pm

zeniko wrote:the listbox differences annoying

I haven't made much use of listboxes yet. Anything to watch out for in cross-browser compatible code?

Phil

XerBlade · Post by **XerBlade** » January 20th, 2006, 8:28 pm

Philip Chee wrote:I'm not too sure what you mean. xSidebar is an extension. Without it the Firefox sidebar hooks aren't available in Seamonkey. I hope that if the Seamonkey sidebar module owner likes it enough that this may make it into Seamonkey 1.5. Unfortunately the current situation is "don't call us we'll call you."

Phil

I'm pretty sure he knows, and that's exactly the point. If you were to make one extension dependent on another extension to work properly (definitely bad practice), the only way to really make your extension feasible would be to include a script to see if the extension it depends on is already installed and install it if it isn't.
That being what IE Tab does on Firefox 1.0.x versions (not required in 1.5+), except to get the plug-in it depends on installed rather than an extension.

old zeniko · Post by **old zeniko** » January 22nd, 2006, 11:48 am

<a href="http://www.haslo.ch/zeniko/software/console2-dev.xpi">Console² v0.3.1.3+</a> should be compatible enough with SeaMonkey that you can actually use it. Sidebar functionality is available, if xSidebar is installed, otherwise you can open it through Tools -> Web Development -> Error Console. The toolbar is simply stuck to the default layout and can't be customized. The listbox proved to be virtually identical to the Toolkit one - I just had some focus problems during the first tests.

As for your install.js: as XerBlade correctly explains, I was wondering why you didn't provide an install.js adapted for xSidebar (which informs the user of the dependency and offers to download and install xSidebar if it isn't present yet) - since otherwise you could just have linked to this install.js...

In the end, there weren't that many differences between the two platforms: viewSource is located somewhere else, .text-link isn't part of the default formatting, there is no closeWindow method and the original console isn't overridable. Most of these details (and the more obvious parts as the toolbar and sidebar differences) are either hardly relevant or easy to work around.

Philip Chee · Post by **Philip Chee** » January 22nd, 2006, 7:00 pm

zeniko wrote:As for your install.js: as XerBlade correctly explains, I was wondering why you didn't provide an install.js adapted for xSidebar (which informs the user of the dependency and offers to download and install xSidebar if it isn't present yet)

Hmm. There are a limited subset of functions that can be called from within install.js. However It looks like I can detect the absence of xSidebar and put up an alert. But I'm not too sure how to download/install another extension from within an install.js.

Thanks for the hints.

Phil

old zeniko · Post by **old zeniko** » January 24th, 2006, 11:49 am

<a href="http://www.haslo.ch/zeniko/software/console2.xpi">Console² 0.3.2</a> brings some minor improvements: toolbar customizability is finally discoverable through the Options menu; Console² officially runs in SeaMonkey, too (with the exception of toolbar customization); and web developers can easily log messages to the console:

Code: Select all

function debug(aMsg, aIsError) { setTimeout(function() { throw new Error((aIsError?"":"[debug] ") + aMsg); }, 0); }

While this code works in all major browsers, Console² displays the messages as messages and not as errors (unless you specify a second parameter with a true value). This might not be as comfortable as having window.dump directly available, but it allows working with this console almost as with FireBug.

Ravenous Bugblatter Beast · January 29th, 2006, 1:47 pm

Can I suggest a few ideas for the next version:

1. Add a context menu item to each error message that allows you to block that specific message. Blocking a message would remove all instances of that error from the same file/line from the console and prevent any more instances being added for the lifetime of the window.

2. Add a "Display Automatically" option that will display the console if it is hidden and an item appears. Or maybe even a sub-menu to choose the level of severity on which the automatic display should occur (error/warning/css etc.)

EDIT: There were previously 3 suggestions here but one was for a feature provided by webdeveloper extension, not console2 - sorry if I confused anyone.

old zeniko · Post by **old zeniko** » January 29th, 2006, 3:21 pm

1. I like that suggestion and will look into it.

2. Should the console also appear if it is closed? That'd be quite difficult, since I don't see how to figure out the console's state in that case (i.e. e.g. whether CSS errors would be displayed at all). Otherwise I'm not sure whether this makes that much sense. Usually you'd rather have the console running in the sidebar all the time, I suppose... The Webdeveloper extension already alerts you in case of a warning/error. Could you describe the use-case of such a feature in some more detail?

3. [The above removed option might still apply to some extent to the console's sidebar capabilities] That's rather a hack for whoever doesn't like that restriction. Apply it yourself either through patching browser.js, overlaying browser.xul or creating a keyconfig shortcut or a userChrome.js entry:

Code: Select all

document.getElementById("sidebar").style.maxWidth="100%";

asqueella · Post by **asqueella** » January 30th, 2006, 4:38 am

zeniko, your version of richlistbox seems to suffer from bug 325159 (Ctrl+click doesn't deselect item)

[Ext] Console² 0.1 to 0.3.6.2

Suggestions