[Ext] Console² 0.1 to 0.3.6.2

[old zeniko]

Do you have any suggestions for improvements?

Sure
<li>don't install any components when doing a profile installation; that's just rude -- and might fail the whole installation when the user doesn't have write access to SeaMonkey's directories
<li>don't set maxVersions without stars (i.e. write 3.0.* instead of 3.0)
<li>write a comment beside each GUID naming the application in clear text
<li>make the new console actually replace the original one (so that you don't have to copy any of the files from bug 334997)

[Philip Chee]

<li>don't install any components when doing a profile installation; that's just rude -- and might fail the whole installation when the user doesn't have write access to SeaMonkey's directories
<li>don't set maxVersions without stars (i.e. write 3.0.* instead of 3.0)
<li>write a comment beside each GUID naming the application in clear text
<li>make the new console actually replace the original one (so that you don't have to copy any of the files from bug 334997)

1. Is there a way of failing silently if this step doesn't work and then skipping to the next line without causing the whole XPInstall to fail?

2. Will Do.

3. You put your comments next to the <targetApplication> line so I was just following your conventions.

4. Not too sure what you mean by that. [edit] The <toolbox> id is different in Console2 so the original SeaMonkey overlay won't apply.

I'm considering putting up a Console2 subpage as part of my extension ports sub-project on xsidebar.mozdev.org, or perhaps (if you are agreeable) to apply for a separate project at mozdev for Console2/ConsoleFilter. I tend to feel nervous if I have code that isn't under CVS control

Phil

[old zeniko]

1. Is there a way of failing silently if this step doesn't work

Just don't do it in the first place: <code>if (!this.profileInstall) { /* install optional components */ }</code>

If a component necessarily has to be installed, there's IMO no point in asking where to install in the first place...

3. You put your comments next to the <targetApplication> line so I was just following your conventions.

Oh, these are alright. I was talking about the ones you added to <kbd>chrome.manifest</kbd>.

4. The <toolbox> id is different in Console2 so the original SeaMonkey overlay won't apply.

You've basically got two options here: (1) have them change the id to <code>ConsoleToolbox</code> because most other ids are also CamelCased and hyphen-less; or (2) change Console²'s toolbox id to <code>console-toolbox</code>. The first would be better for backwards compatibility, the second could be excused with forward compatibility...

or perhaps (if you are agreeable) to apply for a separate project at mozdev for Console2/ConsoleFilter.

Sure, apply for console2.mozdev.org and tell me when I can upload the latest version of my tree (so that it's easier for me to see your changes afterwards)...

[Philip Chee]

Just don't do it in the first place: <code>if (!this.profileInstall) { /* install optional components */ }</code>

Done.

Oh, these are alright. I was talking about the ones you added to <kbd>chrome.manifest</kbd>.

Done

You've basically got two options here: (1) have them change the id to <code>ConsoleToolbox</code> because most other ids are also CamelCased and hyphen-less; or (2) change Console²'s toolbox id to <code>console-toolbox</code>. The first would be better for backwards compatibility, the second could be excused with forward compatibility...

I doubt that the Toolkit people are willing to make any changes that make things easier for SeaMonkey. At one point asaf tried to prevent SeaMonkey people from using blocking1.8.x flags in bugzilla (for shared/core but forked code).

Other problems: consoleOverlay.* files exist only in SM-trunk but not 1.0 nor 1.1. Some of the strings in consoleOverlay.dtd were moved there from console.dtd but not all - some new accesskeys were added on trunk by a general bug to add a bunch of accesskeys all over.

or perhaps (if you are agreeable) to apply for a separate project at mozdev for Console2/ConsoleFilter.

Sure, apply for console2.mozdev.org and tell me when I can upload the latest version of my tree (so that it's easier for me to see your changes afterwards)...

Will do so RSN.

Cheers.

Phil

[msabramo]

This may very well turn out to be a bug with ViewSourceWith, not Console2, but I thought I'd mention it in case anyone else is using both.

Sometimes when clicking on filenames, I am taken to the wrong file and line. At first I thought it was related to setting "Last > First Sort Order" in Console2, but I don't believe this anymore as sometimes it works with that setting and sometimes it doesn't work without that setting.

Any ideas?

I'm using:

Console2 0.3.6.2
ViewSourceWith 0.0.8.39

[Philip Chee]

If you disable ViewSourceWith, does this still happen?

Phil

[incripshin]

I tried installing console2 in seamonkey, and the language is defaulting to German. Is there some way to switch it to English? This is the second computer I've tried it on, so it would be a strange coincidence.

[Philip Chee]

Are you sure that it was German and not Dutch? Try starting SeaMonkey with the command line switch: "--uiLocale en-US".

If you are feeling brave you can edit the chrome.rdf file in your profile/chrome/ directory:

Code: Select all

  <RDF:Description RDF:about="urn:mozilla:package:console2"
                   c:hasOverlays="true"
                   c:baseURL="jar:file:///C:/Documents%20and%20Settings/philip/Application%20Data/Mozilla/Profiles/..../chrome/console2.jar!/content/console2/"
                   c:locType="profile"
                   c:name="console2">
    <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:console2"/>
    <c:selectedSkin RDF:resource="urn:mozilla:skin:classic/1.0:console2"/>
  </RDF:Description>

Look at the c:selectedLocale line. It probably says nl-NL:console2 or de-AT:console2. Change the locale bit to "en-US".


Phil

[incripshin]

You were right, it was Dutch. The problem is fixed, except that in the menu it still shows up as Foutconsole. Is the source code for console2 available anywhere? I suppose I could try to reverse-engineer a source package from the xpi file, but there's a lot of stuff that doesn't end up in there (i.e. comments).

[Philip Chee]

You were right, it was Dutch. The problem is fixed, except that in the menu it still shows up as Foutconsole. Is the source code for console2 available anywhere? I suppose I could try to reverse-engineer a source package from the xpi file, but there's a lot of stuff that doesn't end up in there (i.e. comments).

After editing the chrome.rdf file I found that I had to delete the XUL fastcache file (XUL.mfl on win32 systems) before restarting SeaMonkey.

I'm currently trying to import the source code into the console2.mozdev.org cvs but the CVS server there doesn't seem to understand some of the switches my CVSNT client is sending. .

Phil

[Philip Chee]

Well Console2 is now officially on mozdev: http://console2.mozdev.org/index.html.
The History Page only goes up to 0.3.5 because I can't see where Zeniko documents the changes for 0.3.6.

The instructions for getting the source code can be found here: http://console2.mozdev.org/source.html Although the XPI already contains everything under /src sans the build and check scripts.

Phil

[old zeniko]

Well Console2 is now officially on mozdev: http://console2.mozdev.org/index.html.

Sweet. Now it's finally got its own proper homepage. Can you adjust the homepageURL in install.rdf?

The History Page only goes up to 0.3.5 because I can't see where Zeniko documents the changes for 0.3.6.

Right under the download link.

Could you additionally please mark your version 0.3.6.3+, so that development version can easily be told from official releases? Thanks.

Furthermore, the landing of the new richlistbox changes in bug 298371 might affect Console²'s one (now Toolkit uses mostly the same code which I've been shipping for over a year). Expect some bustage...

[Philip Chee]

Now it's finally got its own proper homepage. Can you adjust the homepageURL in install.rdf?

Sure thing boss!

Could you additionally please mark your version 0.3.6.3+, so that development version can easily be told from official releases? Thanks.

Yessir! (I also need to push my changes to the cvs).

Furthermore, the landing of the new richlistbox changes in bug 298371 might affect Console²'s one (now Toolkit uses mostly the same code which I've been shipping for over a year). Expect some bustage...

Some time back I tried to do a diff between your version and the one from firefox-trunk but they were too different and I couldn't make head or tail of the diff output and gave up.

1. Could you give me a dummies guide to the significance of these changes wrt possible bustage (oh wow, that's a ... large ... patch); and
2. How do you recommend that I handle this?

Phil

[old zeniko]

Sure thing boss!

I hope you get paid properly.

BTW: I've slightly polished the new website. All you have to do now is add your name to the list of contributors...

1. Could you give me a dummies guide to the significance of these changes wrt possible bustage (oh wow, that's a ... large ... patch); and
2. How do you recommend that I handle this?

AFAICT there's hardly any bustage except for some slight CSS issues. Seems that we implemented things mostly in a backwards compatible manner. I'd recommend continuing to use our own richlistbox for some time even on the Trunk, at least until things settled down a bit more (e.g. FAYT stuff is still missing). Once Firefox 3 gets closer to release, you could start using its own richlistbox by making console2.xml#console and console2.xml#item inherit from the native richlistbox.xml and just make sure that you override Firefox' own binding with ours for Toolkit 1.8.* (version specific overriding is possible through chrome.manifest).

[Philip Chee]

Hmm. There are appversion flags but I don't see any flags for toolkit versions?

Phil

p.s. In the past, my name has been misspelt several ways, but this is the first time someone has spelt it with three ps.

Phil