Re: Contextual menu font-size
The font size matches up exactly with the font size of other contextual menus (such as right-clicking an item on the desktop).

Re: Review link
Being looked at.

Re: Arrows
Currently, there's no way. We had planned to have a new window that would show the other results, but we didn't have the time to do it before 4.0.

Re: Tooltip
Lots of people disliked having the tooltip pop up for every result. It's only shown now if there's metadata.

Re: Filter on what's new
Will be there before 4.0.

Re: selections
If an item came in that matched an existing result it will get grouped into that result & raise it's # count. If that happens to move the line up or down (to keep the sorting in order) AND that line was previously selected, then only that line will keep the selection (even if other things were selected). This is necessary (although the behaviour could be improved) because of some bugs with row selection in Java that extend the selection when new results are added or move around.

The 3.9.7 beta is released, with a few minor bug fixes.

Changes include:
- New default list of GWebCaches, thanks to Philippe Verdy.
- Some synchronization fixes related to alternate locations in downloading.
- Ignore errors related to loading native libraries for non-essential utility functions.
- Fixed UI bugs with making tabs visible (Monitor, Connections, Library, etc..).
- Fixed problem with selecting a value in an earlier search result filter not removing the filter from latter boxes.
- Small UI fixes for the Windows L&F on XP.

Hi all (get registered zab--I've been hoping you'd introduce yourself so we all could welcome you and then grill you mercilessly with all sorts of questions )

--Is there supposed to be firewall detection? Both 3.9.6 and 3.9.7 connected as Ultrapeers and didn't pick up on the fact my built-in firewall was ON (I'd forgotten to turn it off). I thought something was odd when I didn't see any incoming in the Connections Pane, and no uploads in Monitors. Luser error, LOL.

--thanks for the update on the previous notes Sam. I mostly use the tooltip to see long filenames (rarely to look at metadata), so will miss that feature in the regular releases.

--I second et voilà's idea of the porn filter being on by default. It won't stop all, but it's at least a bit more than a token gesture.

--btw--I like the way the alternate sources are totaled at the end of the results line. Much more intuitive and informative.

cheers--I'm looking forward to reading the reviews of 4, watching the effect on http://www.limewire.com/english/content/uastats.shtml and hope Philippe's work on the gweb cache's cuts down on the "can't connect" posts.

[edit--spelling correction--sorry]

1) I corrected the spelling of my first name above, 1 L, 2 P, thanks. ;-)

2) This work is not finished. In fact the list of caches will need to be updated regularly (we can see that it should be updated at least once each month, in beta versions, and make sure that a release version contains the latest working list. If a release has been published more than 2 months ago, there should be a minor update to the release branch to update that list in the donwloadable distribution. It is not necessary to advertize this minor sub-version if there's no other significant protocol implementation update or GUI bug correction. So people that have version M.n.x should not be asked to update to version M.n.y, but they may be informed if a version M.(n+1).* is released. Such information should then be displayed automatically on version (M+1).*.*

Downloadable beta versions should also expire after 2 months (so that the user downloads a newer beta, with bugs corrections and performance updates or a release): we've seen that a new component in a beta may cause unexpected problems on the network for its scalibility or on the resources of some other servers on the web.

For CVS version users, the same policy should apply: a user should update its sources to get the new update.ver file at the same time. If a user forgets to get the complete updated sources, the update.ver will expire and beta tests will no longer be helpful as their results will be too old. Some bug corections are essential for a release (some releases will discard temporarily some new components that still don't work as expected, before they get reintegrated in the development branch with their corrections).

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

I'm going to have to disagree with the idea of forced upgrades.

If you want to implement some nagging system, that's fine. There's already the "there's a new version of Limewire" message, that has previously included information about why it's absolutely necessary to upgrade. But, in the end, it was still my decision to install the new version.

I don't see the reason for taking the step from strong encouragement to force. It's enough to make some people suspicious of what all is included in the upgrade and possibly switch clients (or, edit the source to bypass the check).

How does the new proxy option work? Does it alter which IP number I am using?

When spaces are intentionally added into the magnet URI, LimeWire properly wraps the magnet URI in the dialog. Without spaces, no wrapping occurs and it simply makes the width of the window be as wide as the magnet URI is, no matter how long the magnet URI is, even if the resulting dialog doesn't even fit the screen. That is what I was referring to. So if someone actually wanted to read the entire magnet URI, they have to drag the dialog around and if the URI is long enough, it might even be possible that the Yes and No buttons might not even be visible on the screen when copying a magnet URI without having to drag the dialog box around.

Why do you think that I want a forced upgrade?
I was speaking exactly about the condition that makes the "upgrade available" alert to appear. What would be forced is the display of this information box. By "expiring" I mean really the condition that allows a servent to run without this forced message at startup. Users can still dismiss and choose to update later...
But if they ignore it and restart the servent, they will see again this dialog (once).
This is an important feature notably for beta versions and CVS-compiled versions (with its own signed "update.ver" file), so that preliminary code will not harm the network for too long after a major bug is discovered.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

A solution could be to display the message with a specific dialog which includes a scrollable area with autowrap enabled.

The dialog box will still be bounded, and the full URL will still be accessible and readable...

See for example the presentation adopted in the web page displayed when you click on "Show Magnet URI details" for one of your files in your library.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml