Hi, Congrats on a great piece of software. Is there a reason why
JDK 5 support is not a priority?
Looking at the source code, there are only 3 compilation errors
with JDK 5 and all are located in the following file:
com.birosoft.liquid.FileChooserBasicUI
I am not familiar with the code, so I am not sure how hard it would
be to fix these and what other problems there might be when
running JDK 5. However, imho it would be an important
improvement to solve these compilation errors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's a quick hack that makes Liquid LAF compile and
(hopefully) work under JDK 5.0. I have not tested it
thoroughly, so use at your own risk.
In BasicFileChooserUI:
1) Replace the two instances of
ShellFolder.disableFileChooserSpeedFix()
by
true
I haven't found any documentation on this method, but I
guess it's not really vital to have the FileChooserSpeedFix
enabled.
2) replace
files[shouldIndex].compareTo(selectedObjects[actuallyIndex]);
by
files[shouldIndex].toString().compareTo(selectedObjects[actuallyIndex].toString());
This fixes the problem that you can't compare files to
objects in 5.0 without a cast (which might raise an
exception). Comparison of the Strings returned by toString()
(for a file to string returns its path) should be more or
less equivalent to comparing both objects.
With these two fixes compilation succeeds, and apparently
FileChooser does not crash.
Note, that I have not tested this extensively.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've had this problem as well, but only when I try to access a
shared network folder.
I click on the folder (to open it), and it stays in the same
directory, yet it seems to think it's in the folder. If I click on it
again, it causes the CPU to max out / crash.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=798648
I have no plans to fully support JDK 5 yet.
Logged In: YES
user_id=970348
Hi, Congrats on a great piece of software. Is there a reason why
JDK 5 support is not a priority?
Looking at the source code, there are only 3 compilation errors
with JDK 5 and all are located in the following file:
com.birosoft.liquid.FileChooserBasicUI
I am not familiar with the code, so I am not sure how hard it would
be to fix these and what other problems there might be when
running JDK 5. However, imho it would be an important
improvement to solve these compilation errors.
Logged In: YES
user_id=730046
Here's a quick hack that makes Liquid LAF compile and
(hopefully) work under JDK 5.0. I have not tested it
thoroughly, so use at your own risk.
In BasicFileChooserUI:
1) Replace the two instances of
ShellFolder.disableFileChooserSpeedFix()
by
true
I haven't found any documentation on this method, but I
guess it's not really vital to have the FileChooserSpeedFix
enabled.
2) replace
files[shouldIndex].compareTo(selectedObjects[actuallyIndex]);
by
files[shouldIndex].toString().compareTo(selectedObjects[actuallyIndex].toString());
This fixes the problem that you can't compare files to
objects in 5.0 without a cast (which might raise an
exception). Comparison of the Strings returned by toString()
(for a file to string returns its path) should be more or
less equivalent to comparing both objects.
With these two fixes compilation succeeds, and apparently
FileChooser does not crash.
Note, that I have not tested this extensively.
Logged In: NO
I've had this problem as well, but only when I try to access a
shared network folder.
I click on the folder (to open it), and it stays in the same
directory, yet it seems to think it's in the folder. If I click on it
again, it causes the CPU to max out / crash.