Vladimir Sitnikov

I wonder if this could/should be resolved by overriding `RTextArea#getUIClassID`. An alternative option is probably override `TextAreaUI` at the application side. In other words: 1) install LaF 2) Get UI...

> Applying a Theme requires that the object is (almost) completely initialised `Component#updateUI` is invoked when the component is fully initialized. For instance, updateUI is called when LaF is changed,...

>The object (RSyntaxTextArea in this case) is not completely initialised when updateUI is called, attempting to apply a Theme would fail. Is this RSyntaxTextArea bug then? What do you mean...

Well, technically speaking, `setUI` is called before `RSA#` finishes, however, that is a default Swing practice. `JComponent#setUI` calls `ui.installUI(this)` which should configure UI representation, keymaps, etc, for the component.

> psiinon: We're happy to check which LookAndFeel the user has chosen and then apply a suitable RSyntaxTextArea theme, but doing this for all text areas is a pain, especially...

> Another possibility is some sort of factory for RSTA instances, encouraging add-ons to call into that? Could you please compare that to `new JLabel()`? Apparently, addons do not need...

> What's not great about this is if the application wants to change the default Theme at runtime (say to coordinate with a runtime Look and Feel change). Existing RSTA...

>I suggested putting the theme setting code in addNotify() Ah, I see. > Thus we have no "current" Theme check for implementing UIResource Frankly speaking, I think it is implementation...

> Bonus points if a runtime changing of the LookAndFeel re-checks and applies a new Theme Just in case: RTSA is used in Apache JMeter, and on-the-fly LAF change is...

> indifferent between using a UIDefault property or some static global like Theme.getDefault `UIDefault` provides lazy evaluation (`UIDefaults.LazyValue`) and factory (`UIDefaults.ActiveValue`) for free, and it is a common Swing practice....