Choice of file chooser in import sequence is not respected

[Stein Rørvik]

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: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

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: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings,

A side question:  For those with large / multiple monitors, would you like
the ability to increase the font size and place the dialog at a predefined
location of the DirectoryChooser & JFileChooser, similar to GUI Scale and
GenericDialog?

Fred

On Tue, March 9, 2021 5:44 am, Michael Schmid wrote:
> 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: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Stein Rørvik]

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&amp;data=04%7C01%7Cstein.rorvik%40sintef.no
> %7C85380854ca7f48e4735b08d8e2f0d485%7Ce1f00f39604145b0b309e0210d8b32af
> %7C1%7C0%7C637508871300891121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=CK
> Pm0c1YksndxAETWqdwTZzMLS7Tfhwq6NN3gr36xwo%3D&amp;reserved=0
>

--
ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&amp;data=04%7C01%7Cstein.rorvik%40sintef.no%7C85380854ca7f48e4735b08d8e2f0d485%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637508871300891121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=CKPm0c1YksndxAETWqdwTZzMLS7Tfhwq6NN3gr36xwo%3D&amp;reserved=0

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi everyone,

in continuation of the thread
"Choice of file chooser in import sequence is not respected":

Maybe there is a simple way to get a nicer view of the Directory Chooser
on non-Macintosh operating systems.

The following ImageJ macro could help a bit:
 
eval("js","javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName());");

For some flavors of Linux, I fear that this will not be an improvement.
Also note that other javax.swing windows will change their appearance as
well, e.g. the Command Finder (<ctrl>-L).


Thus, I would be interested to get feedback (especially Linux & Windows
users) whether this should be done in ImageJ by default?

To test it, run the macro and then File>Import Image Sequence, and press
the 'Browse' button to get a Directory Chooser (needs at least ImageJ
1.53d).
Also please have a look at Plugins>Utilities>Find Commands and the
'Help' of Edit>Options>Point Tool, whether you like their new appearance.
Users of Jerome Mutterer's Action Panels will also see a changed appearance.

My impression is that the "System Look and Feel" is not a real
improvement under Ubuntu Linux. On other operating systems it may be
different (e.g. on MacOS, where the Directory Chooser is not affected, I
would prefer the SystemLookAndFeel for the Command Finder).

What is your preference?

Michael

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

Hi Michael,
Not sure if this helps, but in opensuse (latest version) running:

> eval("js","javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSys
> temLookAndFeelClassName());");

returns in the Log window:

ReferenceError: "js" is not defined in nashorn:mozilla_compat.js at line
number 69

and the console shows:

Warning: Nashorn engine is planned to be removed from a future JDK release

Cheers

Gabriel
 

> For some flavors of Linux, I fear that this will not be an improvement.
> Also note that other javax.swing windows will change their appearance as
> well, e.g. the Command Finder (<ctrl>-L).
>
>
> Thus, I would be interested to get feedback (especially Linux & Windows
> users) whether this should be done in ImageJ by default?
>
> To test it, run the macro and then File>Import Image Sequence, and press
> the 'Browse' button to get a Directory Chooser (needs at least ImageJ
> 1.53d).
> Also please have a look at Plugins>Utilities>Find Commands and the
> 'Help' of Edit>Options>Point Tool, whether you like their new appearance.
> Users of Jerome Mutterer's Action Panels will also see a changed appearance.
>
> My impression is that the "System Look and Feel" is not a real
> improvement under Ubuntu Linux. On other operating systems it may be
> different (e.g. on MacOS, where the Directory Chooser is not affected, I
> would prefer the SystemLookAndFeel for the Command Finder).
>
> What is your preference?
>
> Michael
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Gabriel,

unfortunately I don't understand the reason for the error, but another
way to try would be entering
 
javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName());

end then Macros>evaluate Javascript [ctrl-j].
(in any case, please remove line breaks introduced by the mailer, it
should be one line).

The Warning "Nashorn engine is planned to be removed from a future JDK
release" does not hurt because javascript is only a simple way to do
what ImageJ could eventually do in Java code.

Best,

Michael
________________________________________________________________________________
On 11/03/2021 11:56 am, Gabriel Landini wrote:

> Hi Michael,
> Not sure if this helps, but in opensuse (latest version) running:
>
>> eval("js","javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSys
>> temLookAndFeelClassName());");
>
> returns in the Log window:
>
> ReferenceError: "js" is not defined in nashorn:mozilla_compat.js at line
> number 69
>
> and the console shows:
>
> Warning: Nashorn engine is planned to be removed from a future JDK release
>
> Cheers
>
> Gabriel
>  
>> For some flavors of Linux, I fear that this will not be an improvement.
>> Also note that other javax.swing windows will change their appearance as
>> well, e.g. the Command Finder (<ctrl>-L).
>>
>>
>> Thus, I would be interested to get feedback (especially Linux & Windows
>> users) whether this should be done in ImageJ by default?
>>
>> To test it, run the macro and then File>Import Image Sequence, and press
>> the 'Browse' button to get a Directory Chooser (needs at least ImageJ
>> 1.53d).
>> Also please have a look at Plugins>Utilities>Find Commands and the
>> 'Help' of Edit>Options>Point Tool, whether you like their new appearance.
>> Users of Jerome Mutterer's Action Panels will also see a changed appearance.
>>
>> My impression is that the "System Look and Feel" is not a real
>> improvement under Ubuntu Linux. On other operating systems it may be
>> different (e.g. on MacOS, where the Directory Chooser is not affected, I
>> would prefer the SystemLookAndFeel for the Command Finder).
>>
>> What is your preference?
>>
>> Michael
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Thursday, 11 March 2021 11:08:22 GMT you wrote:
> javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndF
> eelClassName());

Thanks Michael. Yes that avoids the error to the log window.
However I do not see any difference with Plugins>Utilities>Find Commands or
the 'Help' of Edit>Options>Point Tool. They look the same before and after
running that js line.

Anyway I am just reporting what happens in my linux install in case it helps.

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html