#11 Non-editable non-opaque text areas have weird scrolling behaviour

[Willem3141]

There is a general problem with the opaqueness of text input components.

Apparently many applications use setOpaque(false) to remove the background of the input field. That is a problem, since also if Joxy text components do have a background, it needs to have setOpaque(false) since we have rounded corners.

We thus don't actually know whether the app wants a background or not, and thus we use the following heuristic: if the text field is editable, probably a background is wanted, and if it isn't, the background is omitted.

This is inherently broken and unfortunately there are apps that set setOpaque(true) and setEditable(false). That means that we don't draw all of the background, which gives painting problems. That we see here...

So a solution should be found to read the application's setOpaque setting, while leaving it on false. But in the meantime it might be better to just use setOpaque as if we had no rounded corners, although that also introduces drawing problems.

[Willem3141]

Random idea: keeping our own opaque value (to determine whether the background should be drawn by Joxy), and listening to PropertyChange events to update that value (and setting opaque again on false), might work.

• priority: --> critical

[Willem3141]

You can now see how bad Joxy handles this on the new Text components tab in the test GUI.

Also the case setOpaque(true) and setEditable(true) fails. The opaqueness just never should be true...

[Willem3141]

Okay, I got a plan to finally fix this:

• look what Swing does when a non-opaque component is painted (probably painting a part of its parent);
• do the same thing for all text fields (whether they are opaque or non-opaque *);
• just leave the opacity on whatever it was, and paint the background depending on that.

This should also fix bug [tickets:#14].

* Actually it is only needed to do it when the text field is called opaque. If it was non-opaque, Swing will do it itself.

[Willem3141]

Well, this involves a whole load of private methods in Swing. I don't understand it at all. This is going to be difficult.

We still would like it to be fixed before the 0.1.1 release...

[Willem3141]

We are at the moment busy implementing this, but instead of doing it the hard way, we paint the background of "opaque" text areas with the window background colour. That results in slightly the wrong colour around the text fields, but that can be fixed later.

But if we don't count that small regression, every other symptom of this bug is fixed (for JTextArea, JEditorPane and JTextPane at the moment).

See joxy.utils.PaintHelper for more details.