|
May 13th, 2004
| |||
| |||
 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 Last edited by sberlin; May 13th, 2004 at 02:08 PM. |
|
May 13th, 2004
| |||
| |||
| 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: Code: [Desktop Entry] Type=Application Version=0.9.4 Encoding=UTF-8 Name=LimeWire GenericName=File Sharing Client Comment=Gnutella-based File Sharing Client Icon=/home/user/LimeWire/limewire.ico Exec=/home/user/LimeWire/LimeWire Path=/home/user/LimeWire Categories=Network;FileTransfer 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. |
|
May 13th, 2004
| ||||
| ||||
| Quote:
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.
__________________ LimeWire is international. Help translate LimeWire to your own language. Visit: http://www.limewire.org/translate.shtml Last edited by verdyp; May 13th, 2004 at 06:04 PM. |
|
May 14th, 2004
| |||
| |||
 '?' 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. |
|
May 14th, 2004
| |||
| |||
| 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? |
|
May 14th, 2004
| |||
| |||
| Re: Magnet URI dialog Quote:
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/ |
|
May 14th, 2004
| |||
| |||
| Re: Re: Magnet URI dialog Quote:
|
|
May 15th, 2004
| ||||
| ||||
| 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.
__________________ LimeWire is international. Help translate LimeWire to your own language. Visit: http://www.limewire.org/translate.shtml |
| |
Linear Mode
