hi sdsalsero--glad to see you're still around. I was just thinking of you this morning when a bunch of downloads completed during the night. I was surprised and pleased--Looked like babysitting LW is improved. You seeing an improvement there too? Cheers

sdalsero,

You're 100% correct. Unfortunately, there's not much we can do about it. The installer does not have access to the same system properties that LimeWire does, due to the Installer being a native program and LimeWire being a Java program.

The installer, when choosing whether or not to load LimeWire on system startup will either place the link in the startup folder or not.

LimeWire, when choosing whether or not to load on system startup, with either allow the link that was placed in the startup folder to continue loading or not.

This means that if you've chosen to not load it on startup during the installer, LimeWire itself will still think it's allowed to be loaded on startup even though nothing will be loaded on startup. There's no easy way to have LimeWire place a new icon in the startup folder if one does not already exist (or remove it from the startup folder).

Common problem.

The usual workaround is to place an entry in startup that invokes a small script (or in this case a java program) that checks the relevant config space and runs the app proper if appropriate.

sberlin,
Thanks for the reply. I see the problem now!

Perhaps the Startup icon could be labeled, "LW checker" (or "pre-start" or something?!), to somehow differentiate it from a traditional loader.

As for the Windows installer, the LW java app is storing it's settings in the PREFS file so I don't see why the installer couldn't just modify that. Perhaps that last screen of installer options could clarify that the Startup icon does NOT automatically load LW, but simply checks to see if you've requested that it load (in PREFS). If that seems like too much info, maybe a "More Info" button could be added to that screen?

I know, I know, this is largely a cosmetic issue right now but I certainly hope it can be resolved somehow since it detracts from the "finish" of the product.

3.6 is great. I've been ultrapeer for a day on my imac 450 g3 and cpu usage is between 5 and 20%, while bandwith up and down is under 5Kbytes/sec (means at 4KB/s), uploads are unaffected.

Now I have a NEW feature request for searches:
An option in the search panel to find files bigger than 1 meg (or user defined) in all types, documents, programs and maybe video searches. Why? Because dynamic seraches find easily 160 files for some type of searches, but often 140 out of 160 results are tiny files like readme.txt which 99% of the time I don't even look at (I'm sorting files by size). It is becoming more difficult to find big files because of that (small are easier to find and spread, thus replacing the diversity of big files....). En résumé, rare files might be even harder to find. It might not be a problem to overcome that increasing problem with leaf guidance you have implemented.

Merci de votre attention.

sdalsero:

The problem is precisely that the installer does not know where the limewire.props files will be or is. Java has a different method for finding the home directory on each flavour of windows, and the installer, not written in Java, won't know exactly where it's going to find the file.

et voila:

That's an interesting idea. With the rollout of out-of-band queries, we introduced a feature that would allow something like this to work, but only at search time (it couldn't be dynamically adjusted AND allow more results, although it could be dynamically adjusted to remove extraneous results perhaps).

Sam, haven't you implemented the leaf guidance of bearshare? I though it was. Or are you talking at the search level (ie no protocol variable to define size of files)? Anyway, I think many users would like that feature (including me). An other variation (at the interface level this time, but less powerful as it don't increase the number of big files found) of that option is a size slider that you move to the right to show files in your search that are bigger than... (a kind of a search filter, it might be difficult to implement in java, but many P2P on os x use this).

Merci

Better control over searches would be good. If the first row of the results pane could be search entry boxes (as in Filemaker Pro), this would save screen space and allow the user to set which terms (like size, kind and bitrate) to use, depending on the columns chosen to display search results
Are 'NOT', '>', '<' terms/character likely?

btw--LW is returning search results that seem to be matching path info or perhaps package contents. (a search for "LimeWire" should show this)

Yes, we did implement leaf guidance compatible with BearShare's. The reason that the guidance can't change after the initial search, though, is because the chances are that we already sent a few guidance messages with a higher value, telling the Ultrapeer to shut off the dynamic query. Sending a subsequent message with a lower value will have no effect.

We do plan on implementing some slider-type filters at some point. Expect pretty changes.