Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 19:37:19 GMT, Alexander Zuev wrote:
>> Didn't you answer your question already? If `FileSystemView.getRoots()`
>> returns Desktop in Windows shell namespace. Otherwise, I don't know a way to
>> get a reference to a *virtual* folder in Windows shell namespace which
>> doesn't reference a file system object.
>>
>> Alex's example uses "3D Objects" folder which is one of the known folders
>> and has its own icon instead of the standard folder icon.
>>
>> It's possible that I don't understand the question clearly.
>>
>> Alex's fix affects WindowsPlacesBar on the left of JFileChooser in Windows
>> LaF, the icons there look crispier in High DPI environment.
>
>> But how you got them via this method? I am not sure what parameters should
>> be passed to it.
> `
> String userdir = System.getenv("userprofile");
> Icon icon = FileSystemView.getFileSystemView().getSystemIcon(new File(userdir
> + "\\3D Objects"), 64);
> `
>
> For some of the libraries getting file reference is quite easy, for some -
> not so much. But still doable.
Great!
-
PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 19:11:45 GMT, Alexey Ivanov wrote:
>> But how you got them via this method? I am not sure what parameters should
>> be passed to it.
>
> Didn't you answer your question already? If `FileSystemView.getRoots()`
> returns Desktop in Windows shell namespace. Otherwise, I don't know a way to
> get a reference to a *virtual* folder in Windows shell namespace which
> doesn't reference a file system object.
>
> Alex's example uses "3D Objects" folder which is one of the known folders and
> has its own icon instead of the standard folder icon.
>
> It's possible that I don't understand the question clearly.
>
> Alex's fix affects WindowsPlacesBar on the left of JFileChooser in Windows
> LaF, the icons there look crispier in High DPI environment.
> But how you got them via this method? I am not sure what parameters should be
> passed to it.
`
String userdir = System.getenv("userprofile");
Icon icon = FileSystemView.getFileSystemView().getSystemIcon(new File(userdir +
"\\3D Objects"), 64);
`
For some of the libraries getting file reference is quite easy, for some - not
so much. But still doable.
-
PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 18:16:36 GMT, Sergey Bylokhov wrote: >>> It is accessible from the "JFileChooser" drop-down menu. On my system, the >>> Libraries at that drop down menu contain "GIT", "Documents", "Music". >>> https://docs.microsoft.com/en-us/windows/client-management/windows-libraries >>> >>> There are also "known folders" such as "Network" or "My computer" which do >>> not have a real path but can be navigated in the JFileChooser and has an >>> icon. >> >> Ok, got it. Well, since they can be translated into the file system paths - >> even if these paths do not belong to physical filesystem - they are >> supported by the new API. Not for all of them i am able to receive the high >> resolution icons - like "Recent Items" for some reason only provides 32x32 >> and 16x16 no matter what size i am asking for. Others such as Documents, My >> Computer or 3D Objects do provide all resolutions available. For example >> here's the screenshot of all the available icons for 3D Objects >>  > > But how you got them via this method? I am not sure what parameters should be > passed to it. Didn't you answer your question already? If `FileSystemView.getRoots()` returns Desktop in Windows shell namespace. Otherwise, I don't know a way to get a reference to a *virtual* folder in Windows shell namespace which doesn't reference a file system object. Alex's example uses "3D Objects" folder which is one of the known folders and has its own icon instead of the standard folder icon. It's possible that I don't understand the question clearly. Alex's fix affects WindowsPlacesBar on the left of JFileChooser in Windows LaF, the icons there look crispier in High DPI environment. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 06:32:02 GMT, Alexander Zuev wrote: >> It is accessible from the "JFileChooser" drop-down menu. On my system, the >> Libraries at that drop down menu contain "GIT", "Documents", "Music". >> https://docs.microsoft.com/en-us/windows/client-management/windows-libraries >> >> There are also "known folders" such as "Network" or "My computer" which do >> not have a real path but can be navigated in the JFileChooser and has an >> icon. > >> It is accessible from the "JFileChooser" drop-down menu. On my system, the >> Libraries at that drop down menu contain "GIT", "Documents", "Music". >> https://docs.microsoft.com/en-us/windows/client-management/windows-libraries >> >> There are also "known folders" such as "Network" or "My computer" which do >> not have a real path but can be navigated in the JFileChooser and has an >> icon. > > Ok, got it. Well, since they can be translated into the file system paths - > even if these paths do not belong to physical filesystem - they are supported > by the new API. Not for all of them i am able to receive the high resolution > icons - like "Recent Items" for some reason only provides 32x32 and 16x16 no > matter what size i am asking for. Others such as Documents, My Computer or 3D > Objects do provide all resolutions available. For example here's the > screenshot of all the available icons for 3D Objects >  But how you got them via this method? I am not sure what parameters should be passed to it. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 05:42:46 GMT, Sergey Bylokhov wrote: > It is accessible from the "JFileChooser" drop-down menu. On my system, the > Libraries at that drop down menu contain "GIT", "Documents", "Music". > https://docs.microsoft.com/en-us/windows/client-management/windows-libraries > > There are also "known folders" such as "Network" or "My computer" which do > not have a real path but can be navigated in the JFileChooser and has an icon. Ok, got it. Well, since they can be translated into the file system paths - even if these paths do not belong to physical filesystem - they are supported by the new API. Not for all of them i am able to receive the high resolution icons - like "Recent Items" for some reason only provides 32x32 and 16x16 no matter what size i am asking for. Others such as Documents, My Computer or 3D Objects do provide all resolutions available. For example here's the screenshot of all the available icons for 3D Objects  - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 04:15:41 GMT, Alexander Zuev wrote: >> Maybe we can test this case by just reusing this method where the >> "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That >> old method has the special code for "folder.isLibrary()" so I assume it >> supported the Libraries. And if we will start to use the new method then all >> old tests for the JFileChooser will start to test it. > > What is the library a collection folder such as Recent Items or Documents? It is accessible from the "JFileChooser" drop-down menu. On my system, the Libraries at that drop down menu contain "GIT", "Documents", "Music". https://docs.microsoft.com/en-us/windows/client-management/windows-libraries There are also "known folders" such as "Network" or "My computer" which do not have a real path but can be navigated in the JFileChooser and has an icon. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 03:21:19 GMT, Sergey Bylokhov wrote: >> The JFileChooser supports the libraries since it allows navigation inside >> them. It is done via ShellFolder which extends the file class. The >> FileSystemView feeds the JFileChooser by the data, so it may returns >> "non-file" objects. >> For example the FileSystemView.getRoots() on WIndows will return "new >> Win32ShellFolder2(DESKTOP)". >> >> Usually, when the FileSystemView gets a file object it checks that the file >> is "instance ShellFolder". >> For example, in the newly added method the line "sf = >> ShellFolder.getShellFolder(f);" will check that the file is ShellFolder and >> return it as-is without checking of file existence, and really that path may >> not exist. but if it is a plain file it will check that. >> >> This is why I have asked about virtual folders, do we test them or we can >> consider them as "not existed"? > > Maybe we can test this case by just reusing this method where the > "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That > old method has the special code for "folder.isLibrary()" so I assume it > supported the Libraries. And if we will start to use the new method then all > old tests for the JFileChooser will start to test it. What is the library a collection folder such as Recent Items or Documents? - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 21 May 2021 02:45:15 GMT, Sergey Bylokhov wrote: >> No, libraries are not supported. >> >> I see no contradiction here: `JFileChooser` uses Windows Shell API to >> enumerate objects and navigate the shell namespace. But it does not return >> non-file objects, does it? >> >> The new method accepts `File` object which implies it's a file system object >> rather than an arbitrary object in Windows Shell namespace which cannot be >> represented in Java. > > The JFileChooser supports the libraries since it allows navigation inside > them. It is done via ShellFolder which extends the file class. The > FileSystemView feeds the JFileChooser by the data, so it may returns > "non-file" objects. > For example the FileSystemView.getRoots() on WIndows will return "new > Win32ShellFolder2(DESKTOP)". > > Usually, when the FileSystemView gets a file object it checks that the file > is "instance ShellFolder". > For example, in the newly added method the line "sf = > ShellFolder.getShellFolder(f);" will check that the file is ShellFolder and > return it as-is without checking of file existence, and really that path may > not exist. but if it is a plain file it will check that. > > This is why I have asked about virtual folders, do we test them or we can > consider them as "not existed"? Maybe we can test this case by just reusing this method where the "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That old method has the special code for "folder.isLibrary()" so I assume it supported the Libraries. And if we will start to use the new method then all old tests for the JFileChooser will start to test it. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Thu, 20 May 2021 18:51:54 GMT, Alexey Ivanov wrote: >> So the libraries are not supported? I doubt since JFileChooser should >> support them, and supports of it is one of the reasons why we use shell >> folder to iterate the folders and do not use the javaio. > > No, libraries are not supported. > > I see no contradiction here: `JFileChooser` uses Windows Shell API to > enumerate objects and navigate the shell namespace. But it does not return > non-file objects, does it? > > The new method accepts `File` object which implies it's a file system object > rather than an arbitrary object in Windows Shell namespace which cannot be > represented in Java. The JFileChooser supports the libraries since it allows navigation inside them. It is done via ShellFolder which extends the file class. The FileSystemView feeds the JFileChooser by the data, so it may returns "non-file" objects. For example the FileSystemView.getRoots() on WIndows will return "new Win32ShellFolder2(DESKTOP)". Usually, when the FileSystemView gets a file object it checks that the file is "instance ShellFolder". For example, in the newly added method the line "sf = ShellFolder.getShellFolder(f);" will check that the file is ShellFolder and return it as-is without checking of file existence, and really that path may not exist. but if it is a plain file it will check that. This is why I have asked about virtual folders, do we test them or we can consider them as "not existed"? - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Thu, 20 May 2021 17:37:20 GMT, Sergey Bylokhov wrote: >>> Are we sure that all possible paths can be pointed by the file object? >> >> We specify that we return the icon for a file. If path can not be resolved >> in the file object we can not return the icon for it. > > So the libraries are not supported? I doubt since JFileChooser should support > them, and supports of it is one of the reasons why we use shell folder to > iterate the folders and do not use the javaio. No, libraries are not supported. I see no contradiction here: `JFileChooser` uses Windows Shell API to enumerate objects and navigate the shell namespace. But it does not return non-file objects, does it? The new method accepts `File` object which implies it's a file system object rather than an arbitrary object in Windows Shell namespace which cannot be represented in Java. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Thu, 20 May 2021 16:45:35 GMT, Alexander Zuev wrote: >> We do not test for that in the regression test but i did tested it manually >> and we do return null for the non-existed files. I tested it on non-windows >> platform too. We still return null. > >> Are we sure that all possible paths can be pointed by the file object? > > We specify that we return the icon for a file. If path can not be resolved in > the file object we can not return the icon for it. So the libraries are not supported? I doubt since JFileChooser should support them, and supports of it is one of the reasons why we use shell folder to iterate the folders and do not use the javaio. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Thu, 20 May 2021 16:06:37 GMT, Sergey Bylokhov wrote: >> Are we sure that all possible paths can be pointed by the file object? >> Especially some "Windows Libraries" which are accessed by the shell folder? > > Later we say that this method returns null for non-existed files. is it > always correct? I am not sure that the file created for the library report > true for the exists() method; DId we test this usecase? We do not test for that in the regression test but i did tested it manually and we do return null for the non-existed files. I tested it on non-windows platform too. We still return null. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Thu, 20 May 2021 16:43:05 GMT, Alexander Zuev wrote: >> Later we say that this method returns null for non-existed files. is it >> always correct? I am not sure that the file created for the library report >> true for the exists() method; DId we test this usecase? > > We do not test for that in the regression test but i did tested it manually > and we do return null for the non-existed files. I tested it on non-windows > platform too. We still return null. > Are we sure that all possible paths can be pointed by the file object? We specify that we return the icon for a file. If path can not be resolved in the file object we can not return the icon for it. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Thu, 20 May 2021 07:40:35 GMT, Sergey Bylokhov wrote: >> Good catch! Yes, fixed both here and in CSR. > > Are we sure that all possible paths can be pointed by the file object? > Especially some "Windows Libraries" which are accessed by the shell folder? Later we say that this method returns null for non-existed files. is it always correct? I am not sure that the file created for the library report true for the exists() method; DId we test this usecase? - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Mon, 17 May 2021 05:08:13 GMT, Alexander Zuev wrote:
>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java
>> line 271:
>>
>>> 269: * Example:
>>> 270: * FileSystemView fsv = FileSystemView.getFileSystemView();
>>> 271: * Icon icon = fsv.getSystemIcon("application.exe", 64);
>>
>> Shouldn't the first parameter be a File instance instead of String?
>> `Icon icon = fsv.getSystemIcon(new File("application.exe"), 64);`
>
> Good catch! Yes, fixed both here and in CSR.
Are we sure that all possible paths can be pointed by the file object?
Especially some "Windows Libraries" which are accessed by the shell folder?
-
PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Sun, 16 May 2021 18:49:24 GMT, Alexander Zvegintsev
wrote:
>> Alexander Zuev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Slight change of wording in javadoc
>> Fixed Win32ShellFolder2.getSystemIcon scaling issue
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java
> line 271:
>
>> 269: * Example:
>> 270: * FileSystemView fsv = FileSystemView.getFileSystemView();
>> 271: * Icon icon = fsv.getSystemIcon("application.exe", 64);
>
> Shouldn't the first parameter be a File instance instead of String?
> `Icon icon = fsv.getSystemIcon(new File("application.exe"), 64);`
Good catch! Yes, fixed both here and in CSR.
-
PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
On Fri, 14 May 2021 19:46:03 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional > commit since the last revision: > > Slight change of wording in javadoc > Fixed Win32ShellFolder2.getSystemIcon scaling issue Marked as reviewed by aivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v7]
> Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Slight change of wording in javadoc Fixed Win32ShellFolder2.getSystemIcon scaling issue - Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/10bae9be..4cd5a508 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2875=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2875=05-06 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875
