On Fri, 31 Jul 2026 17:59:10 GMT, Phil Race <[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. @prrace I have worked on a patch to configure LookAndFeel.installProperty to set it false for all L&F except Aqua Shall I go ahead and update the patch or do you have something else in mind to try? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32101#issuecomment-5176058292
