On Thu, 30 Jul 2026 11:09:00 GMT, Prasanta Sadhukhan <[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
