Posted by
Stein Rørvik on
Mar 09, 2021; 9:59pm
URL: http://imagej.273.s1.nabble.com/Choice-of-file-chooser-in-import-sequence-is-not-respected-tp5024507p5024513.html
Sorry for not writing about my OS, I am using Windows 10 / 64 bit.
Yes you are right that this seems to be a limitation of the DirectoryChooser not Import Sequence per se. When I checked again, I see that the native dialog we had an option for in Import Sequence in older versions of ImageJ was a file chooser, not a directory chooser. The file chooser expected you to select the first file in the folder, and then the sequence import treated the parent folder as the folder to import files from. This still works as a good solution for Import Sequence, as one can then double check the file names to verify that this is indeed the folder one wants to import data from.
The JFileChooser kinda works, but it is a bit awkward on Windows. The same generic icon is shown for both files and folders, and it is difficult to expand the column width. It is also very slow compared to the native file chooser.
Stein
-----Original Message-----
Sent: 9. mars 2021 12:45
Subject: Re: Choice of file chooser in import sequence is not respected
Hi Stein,
which operating system are you using?
As far as I see, the DirectoryChooser can use the native Chooser of the operating system only for Apple Macintosh. On Windows and Linux it seems that there is no way to have a java.awt.FileDialog asking for a directory, not a file.
I have compared ImageJ 1.49 and a recent version; the DirectoryChooser code looks very similar in this respect. Under Linux I also did not experience any changes in the recent years.
A way around would be a GenericDialog with addDirectoryField; this is drag&drop-enabled, so one can avoid using the DirectoryChooser by dragging a directory from the file manager (windows Explorer).
<What I would consider a nice feature, but it is currently not present, is having the drag&drop onto a DirectoryField also work when dragging files contaainded in a directory; very often one has the directory open in the file manager (Explorer, Finder...). This means, automatically stripping off the filename, i.e., using File.getParent().>
And a further idea: Would it be possible to make the JFileChooser in ImageJ at a bit more user-friendly?
- By enabling drag&drop
- With UIManager.html.getCrossPlatformLookAndFeelClassName, to have it look at least a bit more like the native dialog.
Unfortunately, having a JFileChooser with good Windows Look&Feel seems to require com.sun.java.swing.plaf.windows.WindowsLookAndFeel, but this is not present in OpenJDK (Oracle Java seems to have it at least up to Java 8).
Michael
________________________________________________________________
On 09.03.21 09:51, Stein Rørvik wrote:
> We have under I/O options two choices:
>
> "Use JFileChooser to open/save"
> and
> "Use file chooser to import sequences"
>
> The former works as it should: If checked, the JFileChooser dialog is used when opening and saving files, and the native open/save file dialog box is used when unchecked.
>
> The problem is that the JFileChooser dialog is always used for the file/folder choice when importing sequences, both when "Use file chooser to import sequences" I/O option is checked and unchecked. So this choice is not respected.
>
> It appears that this problem was introduced when the new main dialog for file import was introduced in 1.53d. So I am talking about the dialog box that now appears after pressing the "browse" button. The main dialog still works as it should, also with drag-and-drop.
>
> Also, JFileChooser seems to always be active for the getDir("Choose a Directory") function; the setOption does not disable it in the following:
>
> setOption("JFileChooser", false);
> getDir("Choose a Directory");
>
> Perhaps these problems are related, that it is the same dialog as in the getDir("Choose a Directory") function that is called upon a click of the Browse button in the import dialog?
>
> JFileChooser does not work well on my system, so I prefer to have an option to disable it for all cases.
>
> Stein
>
> --
> ImageJ mailing list:
>
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage> j.nih.gov%2Fij%2Flist.html&data=04%7C01%7Cstein.rorvik%40sintef.no
> %7C85380854ca7f48e4735b08d8e2f0d485%7Ce1f00f39604145b0b309e0210d8b32af
> %7C1%7C0%7C637508871300891121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CK
> Pm0c1YksndxAETWqdwTZzMLS7Tfhwq6NN3gr36xwo%3D&reserved=0
>
--
ImageJ mailing list:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=04%7C01%7Cstein.rorvik%40sintef.no%7C85380854ca7f48e4735b08d8e2f0d485%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637508871300891121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CKPm0c1YksndxAETWqdwTZzMLS7Tfhwq6NN3gr36xwo%3D&reserved=0--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html