SWT Class Hierarchy: A Criticism

From time to time, I find something odd with SWT class hierarchy, which causes me to code more. The only explanation I could tell to myself is that SWT is trying to have its API as easy as possible. But this easy-thinking could be sometimes really frustrating.

I express here 4 examples:

1. Combo and CCombo are two classes with rather same interface (say ICombo), but in fact there is no common interface defined in SWT. Here is a case that happened to me; I had a number of (big) combo boxes in a SWT application, which worked fine in Windows. When I wanted to run the application on Linux, since setVisibleItemCount(int) is not implemented on GTK (actually not possible due to the way GTK combos are implemented: either a list+button or menu+button), combos covered the whole screen. If there was a common ICombo interface, I could easily change all the Linux combos to CCombo (which supports that method).
2. setText()/getText() is a very common method among widgets, which is not forced by any interface. Suppose a case that you want to implement a number of different table editors (a CCombo and a Text as an example), with a common listener. If there was an interface for widgets (like IWidget), you could then use that to handle all the table columns regardless of column number.
3. Button is another example. Why should checkbox, radio button, and normal button use the same class, and for example getSelection doesn't work for button? Neither SRP, nor LSP are held here.
4. There would be fine to have a simple (either without any method) interface for layout data classes. setLayoutData(Object) would better to accept a special interface, rathe bare Object :).