I saw some disabled controls that totally forbid user input, which is annoying: you cannot scroll them, you cannot select text to copy it, etc. In this case, a read-only mode can make sense.
Agreed. TextArea should support an "editable" vs. disabled mode, and it does (or will, when it is complete). For other components (such as buttons), it doesn't make sense.
If your Label supports scrolling and selecting, it might make sense as a read-only text input. If disabled TextInput supports it, it is indeed perceived as read-only. Otherwise, the read-only mode can be interesting.
Label doesn't currently support selection, and probably won't, since you'll ultimately be able to get the "non-editable but selectable" behavior from TextArea. I can see what you mean about TextInput, but I'm still on the fence. Maybe some example use cases would help.
BTW, I wanted to check against your demos, so I went to the Kitchen Sink one. I had to open it in Safari because for some reason it freezes my Firefox 3 tonight (it is not the most stable lately).
We currently require Safari, though hopefully this will be fixed when Snow Leopard is released (see the FAQ: http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html) .
Anyway, I opened the Text fold, and saw some oddities. Perhaps they have been fixed already. The Label doesn't allow selecting, which isn't really surprising, but the TextArea doesn't allow it either, which is more surprising.
TextArea is still incomplete. That's why there is a big "PREVIEW" watermark on it in the demo. :-)
There is another glitch: scroll the demo pane so that the TextArea is half hidden by the bottom limit of the applet. Scroll the TextArea (with its scroll bar): the scrolled part goes down to the lower limit of the applet (including the bottom scroll bar).
Hm. I tried to follow these steps but didn't see any odd behavior. Can you send a screen shot?
