>> Do you have a list of these ?
I found 8 cases in Aqua LAF where UIResource and LookAndFeel.installProperty are used directly, but there are many more in Basic LAF classes that are probably used indirectly. >> If the current L&F is (eg) Nimbus when the component is created even the >> application explicitly sets it to false, >> then Aqua is installed, it will set it to true. This doesn't seem right to >> me. I agree. I am not defending the current implementation. To fix this problem, LookAndFeel.installProperty would need to be extended to support dragEnabled. >> The problem is it ignores what the app sets and doesn't behave as the docs >> say. I agree that Aqua ignores what the app sets. The documentation could be clearer. It is technically correct in the sense that the default value is false before any UI is installed. See the documentation of JComponent.setAutoScrolls; it says the default value is false, but BasicTextUI sets it to true. > On Jul 31, 2026, at 11:01 AM, Phil Race <[email protected]> wrote: > > On Thu, 30 Jul 2026 11:09:00 GMT, Prasanta Sadhukhan <[email protected] > <mailto:[email protected]>> wrote: > >> Aqua classes for text components enables dragEnabled by default although >> setDragEnabled spec cites `"The default value of the dragEnabled property is >> false. "` and there is nothing in Aqua L&F that mentions otherwise as to why >> the default is overridden. >> Other L&F dont override the mode and the code is there from macosx port days >> so it seems to be an oversight. >> >> The code is deleted. >> Test is added to check >> - default value is honoured in all installed L&Fs >> - explicit application setting of drag mode is preserved on L&F change >> >> CI testing is ok. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > >> _Mailing list message from [Alan Snyder](mailto:[email protected]) on >> [client-libs-dev](mailto:[email protected]):_ >> >> There are many examples where the Aqua LAF overrides a property only if the >> property has not been set by the application. So, I think this behavior is >> kosher, even if it could be surprising. I’m not sure why this case should be >> different. > > Do you have a list of these ? It doesn't have to be exhaustive, but it should > be representative. > > Also in this case, it seems that Aqua can over-ride / ignore the application > setting. > > If the current L&F is (eg) Nimbus when the component is created even the > application explicitly sets it to false, > then Aqua is installed, it will set it to true. This doesn't seem right to me. > > Next, if the app did not set it until after Aqua is installed, then the app > explicitly sets it to true, changing back to Nimbus it will revert to false > with the current code, thus disobeying the app. > > If we can't find a way to know if it was an app setting then I think the Aqua > behaviour should be removed. > > Also this is not a clear-cut case where the Swing app must follow the desktop > default. > For an app that doesn't want D&D, it may be surprising that it is enabled. > >> This way of describing the behavior might be clearer than saying that the >> default may be LAF dependent, which does not acknowledge that the LAF might >> set the property. >> >> In wishful thinking mode: What is lacking is a way for a LAF to interpose on >> a property — making a distinction between the application-specified value >> (which might be an explicit value meaning “use the default behavior") and >> the implementation behavior. > > Swing uses the UIResource interface to distinguish some cases of app setting > vs Swing default. > But I'm not sure that can be retro-fitted here. > >>>> Aqua LAF is designed to mimic both the appearance and *behavior* of native >>>> components. >>>> The documentation states that a LAF can ignore this property. That could >>>> be interpreted as ignoring the property regardless of whether the value is >>>> true or false, not just when it is true. > > But Aqua does NOT ignore it. It always honors the current setting. The > problem is it ignores what the app sets and doesn't behave as the docs say. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/32101#issuecomment-5145966819
