[Ext] InfoLister [old 2004-2010 thread]

[Peng]

Hey, when is 0.9d going to be released? I downloaded '0.9d-pre' on December 7th, and it's worked fine for me in builds from the mozilla1.8 branch. Do you want to change more things in it before releasing it?

[asqueella]

onemen: I don't support trunk builds, sorry.

Peng: I'm not working at the extension right now, sorry. Everybody is free to use 0.9d, if they wish.

[xal]

i'm getting
Error: Components.classes['@mozilla.doslash.org/infolister/service;1'] has no properties
Source file: chrome://infolister/content/common.js
Line: 171

on 1.5 on fedora core 4

[Peng]

Peng: I'm not working at the extension right now, sorry. Everybody is free to use 0.9d, if they wish.

Well, okay. If there are any decent changes, you could release it though. I don't think it would take that long to do..

[asqueella]

Peng: right, but then people not interested in those changes would get an unneeded update, and people on UMO would have to spend time reviewing the extension again. There were a single fix, as I understand, right? It's not enough for a new version IMO.

xal: thanks for reporting. I need more details as to how did you get it in this state, though. Did you just install InfoLister and it didn't work? Did you upgrade Firefox recently? Is it the latest version of InfoLister (i.e. 0.9c or d)

That message indicates the component didn't get registered. Reinstalling should help you, but it is not supposed to happen in first place, so I'd like to find out what is the cause for this and file a bug against moz.

[Bazon]

Peng: I'm not working at the extension right now, sorry. Everybody is free to use 0.9d, if they wish.

Oh, that's sad, I'd love to see/have an infolister version which finds the correct xpi-Link... (You know, I told before. It doesn't even find it's own xpi-link but the link to Infolister 0.82.xpi...)

onemen: I don't support trunk builds, sorry.

Well, at least in my trunk (Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a1) Gecko/20060114 Firefox/1.6a1 ID:2006011503) it's (IL 0.9d) running very well

[Dr. Evil]

Bazon asked at the German Firefox Forums for a modification of Infolister that would return the right version of an extension. So I wrote this patch that should always return the xpi with the highest version:

Code: Select all

--- Infolister/orig/chrome/content/components/xpiLinks.js   Sun Oct 23 21:57:04 2005
+++ /Infolister/chrome/content/components/xpiLinks.js   Sat Jan 21 15:35:14 2006
@@ -191,20 +191,35 @@
   var updatesCont = CC["@mozilla.org/rdf/container;1"].createInstance(CI.nsIRDFContainer);
   updatesCont.Init(datasource, updates.QueryInterface(CI.nsIRDFResource));
 
-  // for simplicity, we take the first version we find (it's usually the one we want)
-  var versionInfo = updatesCont.GetElements().getNext().QueryInterface(CI.nsIRDFResource);
-  var targetApps = datasource.GetTargets(versionInfo, gRDF.GetResource(XMLNS_EM + "targetApplication"), true);
-  while (targetApps.hasMoreElements())
+  // find the highest version of this extension:
+  var versionInfo, currentVersion;
+  var highestVersion = "-*";
+  var targetApps, targetAppInfo, targetAppID;
+  var updateLink = "";
+  var version = updatesCont.GetElements();
+  while(version.hasMoreElements())
   {
-    var targetAppInfo = targetApps.getNext().QueryInterface(CI.nsIRDFResource);
-    var targetAppID = datasource.GetTarget(targetAppInfo, gRDF.GetResource(XMLNS_EM + "id"), true).QueryInterface(CI.nsIRDFLiteral).Value;
-    if (targetAppID != appID)
-      continue;
+    versionInfo = version.getNext().QueryInterface(CI.nsIRDFResource);
+    currentVersion = datasource.GetTarget(versionInfo, gRDF.GetResource(XMLNS_EM + "version"), true);
+    if(CC["@mozilla.org/xpcom/version-comparator;1"].getService(CI.nsIVersionComparator).compare(currentVersion, highestVersion) > 0)
+    {
+      // is it compatible to this app?
+      targetApps = datasource.GetTargets(versionInfo, gRDF.GetResource(XMLNS_EM + "targetApplication"), true);
+      while (targetApps.hasMoreElements())
+      {
+        targetAppInfo = targetApps.getNext().QueryInterface(CI.nsIRDFResource);
+        targetAppID = datasource.GetTarget(targetAppInfo, gRDF.GetResource(XMLNS_EM + "id"), true).QueryInterface(CI.nsIRDFLiteral).Value;
+        if (targetAppID != appID)
+          continue;
 
-    var updateLink = datasource.GetTarget(targetAppInfo, gRDF.GetResource(XMLNS_EM + "updateLink"), true);
-    if (updateLink)
-      return updateLink.QueryInterface(CI.nsIRDFLiteral).Value;
+        updateLink = datasource.GetTarget(targetAppInfo, gRDF.GetResource(XMLNS_EM + "updateLink"), true);
+      }
+    }
   }
+
+  if(updateLink)
+    return updateLink.QueryInterface(CI.nsIRDFLiteral).Value;
+
   return "";
 }



[asqueella]

Thanks!

The new version, http://mozilla.doslash.org/infolister/i ... 0.9d.1.xpi (loosely based on your code), should collect the correct links now.

[Bazon]

Great!
Thank you both!

[Peng]

Well, just to say, I've been using InfoLister 0.9d.1 for maybe 22 hours, and it works fine. I don't use the XPI links code, but I can confirm that InfoLister hasn't exploded into a firey mess yet.

[pigsonthewing]

InfoLister is superb...

(there's always a 'but')


...but it's case sensitive. I sort my extensions using "Ext2ABC", which isn't case sensitive, then compare my extension list with the output of InfoLister on three other machines. If was(optionally) case insensitive, my life would be made easier.

Better still, if InfoLister could compare its output on a local machine, with that produced on another, then draw up a list of extensions missing, or requiring upgrade, that would be grand!

Thank you.

[Peng]

...but it's case sensitive. I sort my extensions using "Ext2ABC", which isn't case sensitive, then compare my extension list with the output of InfoLister on three other machines. If was(optionally) case insensitive, my life would be made easier.

Yup, case-insensitive sorting would be nice. I don't think a preference is necessary. I think most people would agree that case-insensitive is better for this, and the ones that disagree will live.

Better still, if InfoLister could compare its output on a local machine, with that produced on another, then draw up a list of extensions missing, or requiring upgrade, that would be grand!

Hmm. That would be a neat feature.

[pigsonthewing]

InfoLister is superb...

(there's always a 'but')

It would also be good if, indetad of just:

* [Ext name linking to home page]
* [version number]

the ouput could include

* [Ext name linking to home page]
* [version number]
* [link to .xpi]
* [checkbox]

and the check box could be used to do things like:

* save all .xpi files oin a directpry
* install all extensions now

[asqueella]

These all sound like good ideas for custom templates. Unfortunately I don't think I'll write those anytime soon (although the one for installing checked extensions is already >made by Bazon and Mithrandir<)

[gemal]

It would be really nice if it was possible to list what updateURLs each extension had. Extensions that dont have an UpdateURL uses addons.mozilla.org which isn't up to date all the times. This way I could check my extension list for extensions that I want to go to their real homepage to check for updates for.