> I wonder whether this can work - code outside the o.n.swing.plaf should not > be able to instantiate/access the class (it is not an exported class9.
This seems to be the way things are done in this module; not sure how it works. For example, o.n.swing.plaf.aqua.AquaSeparatorUI is registered and initialized in a similar manner. Just to be sure, I added a stacktrace dump from SmoothScrollPaneUI.createUI. On Java 10, it definitively gets called: ``` org.netbeans.swing.plaf.util.SmoothScrollPaneUI.createUI(SmoothScrollPaneUI.java:103) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at jdk.internal.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at java.desktop/javax.swing.UIDefaults.getUI(UIDefaults.java:804) at java.desktop/javax.swing.UIManager.getUI(UIManager.java:1065) at java.desktop/javax.swing.JScrollPane.updateUI(JScrollPane.java:391) at java.desktop/javax.swing.JScrollPane.<init>(JScrollPane.java:306) at java.desktop/javax.swing.JScrollPane.<init>(JScrollPane.java:324) at org.netbeans.modules.editor.NbEditorUI.createExtComponent(NbEditorUI.java:234) at org.netbeans.editor.EditorUI.getExtComponent(EditorUI.java:929) at org.netbeans.modules.editor.NbEditorDocument.createEditor(NbEditorDocument.java:176) at org.openide.text.CloneableEditorInitializer.initCustomEditor(CloneableEditorInitializer.java:511) ``` I also confirmed, via print statements, that SmoothScrollPaneUI ends up receiving and processing mouse wheel events in the editor and other IDE scroll panes (e.g. the Projects sidebar panel). As for BasicScrollPaneUI, that one does seem to be public (but you were probably talking about SmoothScrollPane). See https://docs.oracle.com/javase/9/docs/api/javax/swing/plaf/basic/package-summary.html . > Neither Metal, Nimbus nor GTK LAF enter the conditional in > Startup#installSmoothScrollPane (line 266) they all come with their custom > implementation for ScrollPaneUI. That's correct; I intended this patch to be a little more conservative than the original IntelliJ patch. The original IntelliJ patch applied to all subclasses of BasicScrollPaneUI (via reflection), not just plain BasicScrollPaneUI. Testing NetBeans on the Metal LAF on Windows reveals that Metal _does_ have the same scrolling problem as the default Windows LAF did prior to this patch. So in theory it would benefit from the same fix. But since Metal and other LAFs have their own ScrollPaneUI implementations, applying the fix would require either (1) creating a new subclass for each LAF, or (2) using reflection to replace the private mouseScrollListener field as was done in the original IntelliJ code. The latter seems fragile, and when I did it, I got stern console warnings from Java warning that the particular reflective access in question might not be permitted in the future. So for now, this patch only affects the Windows LAF. Which LAF is the default on Linux? (Is it the same for all distros?) Is there a similar scrolling problem there that might benefit from a more generalized version of this patch? Note that the MacOS (Aqua) LAF does not require this patch; it already has nice smooth scrolling. [ Full content available at: https://github.com/apache/incubator-netbeans/pull/881 ] This message was relayed via gitbox.apache.org for [email protected]
