LimeWire 3.9.12 is released.

Changes in 3.9.12 include:
- Added workaround for faulty JIT on OSX 10.2 with Java 1.4.1. Previously TigerTree hashes were corrupted because of this bug.
- Added status of what core components are loading just after the GUI becomes visible.
- Removed 'Chat' buttons from downloads & search results. (You can still chat from the right-click menu.)
- Fixed sorting on location column.

In five days LimeWire 4.0 will be released.

Thanks,
The LimeWire Team

KDE/Gnome Menu Entries
 

Could future versions of LimeWire's installer in Linux drop in KDE/Gnome menu entries?

The guide at:
http://freedesktop.org/Standards/des...ry-spec/0.9.4/
explains how to format a ".desktop" file.

http://www.freedesktop.org/standards...8/ar01s02.html
and http://freedesktop.org/Standards/bas...6/ar01s03.html explain where to place the ".desktop" files.

On SuSE 9.0, none of that XDG environment variable stuff seems to be defined so, $HOME/.local/share/applications/ works as a decent place to drop in a ".desktop file when the installer is being run as a normal user. When it is being run as root, it should drop a ".desktop" file in /usr/share/applications/ and it would appear on all user's menus.

Following their specification, a working ".desktop" file I created looks like this:
If LimeWire is ever uninstalled, removing its entry is as easy as removing the LimeWire.desktop file it dropped in $HOME/.local/share/applications/ or /usr/share/applications/ (and possibly also rebuilding the menu cache if the uninstaller is run within kde using "kbuildsycoca" but I don't think that is required).

The specs at www.freedesktop.org regarding .desktop entries seems to work ok in KDE 3.1.4, I haven't tested any other environment though.

Note that this bug occured only on Mac OSX 10.2. The compiled code was correct, just executed incorrectly by the Mac version of Java 1.4.1. If someone, using this OS for Java programming knows how to avoid this problem or why it occurs, it could be helpful to investigate it , because the bug does not occur when LimeWire is run in interpreted mode (-Xint) without JIT enabled.
Sam posted a bug report to Apple, but this also indicates possible unpredicable bugs elsewhere in other parts of LimeWire or in any other Java application.

The bug is isolated and reproductible with the two classes published in the GDF Files section that implement and test the "Tiger" MessageDigest,:where there's a separate extensive test class that demonstrate correct results on Windows, Linux, Unix, Mac OSX 10.1, 10.3 or other versions of Java on OSX 10.2.
Shamely for OS X 19.2 i affects the latest version of Java for that platform. So this is a regression bug of Java. The precise condiions for which this bug occurs are unknown.

May be there's a way to remove some code optimizations to make the class work on Java 1.4.1/OSX10.2. For now Cryptix will be used, but it's much slower and it will require an extra JAR file.
I wrote his class, but I have no Mac OSX to investigate it.

'?' in filenames
 

I am in the process of downloading some songs from another user, but alas two of the titles have question marks (fairly common in song titles). For example:
Should I Be Sweet?

This song is listed in the Search results, but when I click on it, I get a "Need more sources" message which I assume is a "File not found" error message on the remote machine. According to the Results window it is running Lime, but alas doesn't indicate which version.

On my OS (OS/2), question marks aren't allowed in filenames, and for better or worse I have been forced to get in the habit of removing them. Apparently, this individual is using an OS which does permit them, but his/her version of LimeWire isn't taking this into account. Is this a current issue or has this been fixed in earlier versions?

Thanks and keep up the good work.

in 3.9.12 beta pro on 10.3.3, the filters sometimes switch to audio, and stick there, after a repeat search (no filters active before the repeat search was chosen). I ran out of time to nail down the steps required to repeat. The screen shot shows all filters set to "All" but the results locked into "Audio"
ps--is the clarity of these screenshots OK? Too large?

Re: Magnet URI dialog
 

we are experimenting with a new linux installer which does that (and is faster, better looking, has less carbs...)

It will not be in for 4.0 and for at least a week or two afterwards though. If you are interested in helping, check out http://bitrock.com/

Any areas you want us to concentrate on this weekend?

Try everything you possibly can to break LimeWire. That's about it.

Re: Re: Magnet URI dialog
 

I tried out their installer and it definitely is looking nice!

Could I suggest to override the SetToolTipLocation() method for the JMultiLineToolTip so that the tooltip will not extend below the bottom limit of the visible desktop? (the tooltip will not display completely, not ably for rows in the Connections table).

The default computed location just attempts to position the tooltip below the mouse cursor position, and adjusts it above to make it fit in the physical screen, but not on the visible desktop.
With my bottom desktop toolbar, this hides about 4 lines of the tooltip text.

One suggestion would be that if the mouse is at or below the middle of the screen height, then the location should be set above the mouse cursor rather then below it, keeping the adjustment to avoid it to go above the top of the physical screen.

Also, tooltips for table rows may better be aligned horizontally with the hovered table cell for which the tooltip is displayed. Clicking on the tooltip should have the same effect as clicking on the table cell, after the tooltip is closed, if the cell is editable and the tooltip does not spans on several lines (for example when renaming files). If the tooltip can fit on the cell space, and the cell is fully within the visible desktop area, then there's no need to move it above or below the mouse cursor.