I tried mocking this up with auxiliary look and feel first, and it failed horribly, hence the current approach. Not sure if the problem was something broken in JDK-14 - my goal was just to demonstrate it could be done, so I moved on. In general, auxiliary look and feels tickle a lot of very rarely touched code-paths in Swing; I'd expect breakage. And it, too, changes the type of the look and feel you get from UIManager.getLookAndFeel(), so there's no clear win if you want to avoid that.
All of the look and feel checking code *I ever wrote* and all of the code Dafe Simonek wrote for the look and feel support in core tests on lookAndFeel.getId(), which is the correct way to test that. I don't know if anything elsewhere is doing it wrong - I suppose there might be a case or two - but it ought to be pretty easy to find. -Tim On Mon, Sep 21, 2020 at 10:03 AM Neil C Smith <[email protected]> wrote: > On Mon, 21 Sep 2020 at 13:58, Tim Boudreau <[email protected]> wrote: > > The objection I forsee is "But that would mean aggressively loading stuff > > into UIManager from every module". > > Surely only if you don't want to fix the problem?! > > > So here's how you solve that (the > > delegating look and feel stuff would live in core.swing.plaf and just > wrap > > the LookAndFeel that's currently set on startup; > > I think delegation would break a bunch of hideous code that checks for > LaF in many modules. But auxiliary LaF might work for this? > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- http://timboudreau.com
