RE: RE: [platform-swt-dev] org.eclipse.swt.SWT

["Erik Poupaert" <erik.poupaert@xxxxxxxxx>]

>>>>> On the other hand, the whole constants/flag thing is pretty weak.  For
one
>>>>> thing, it's not clear by looking at a component class what properties
it
>>>>> supports.  You have to look at the JavaDocs to find out.  It's just
plain
>>>>> unwieldy trying to track down which SWT constants apply to which
components.

There are a number of design decisions in SWT that I consider:
not-what-I-would-have-done. This is definitely one of them. Another one is
org.eclipse.swt.widgets.TypedListener. Go and have a look at that one. That
is truly a showstopper to scalability. SWT does not necessarily excel in its
design beauty, certainly not everywhere.

What I find very good about SWT, is the fact that its results are really
nice and that it is multiplatform. Swing probably has a better looking
design, but its results are not always what we like. Further, I use SWT
jointly with GCJ to compile native applications. Swing would be out of the
question, because Gnu Classpath doesn't implement it (sufficiently), and
therefore, I would still be stuck with bytecode, it's startup conundrum, and
dragging around a JRE for deployment. My average GCJ/SWT executable is
self-contained and less that 1 Mb (with cheating because I compress with
upx). At present, there is no substitute for the combination GCJ and SWT.

So, it may be true that SWT is not designed nicely everwhere, but that fact
is compensated by other characteristics which make it a unique proposition.

>>>>> As components get extended and the API grows, this is just going to
get
>>>>> worse.

Bah. I hope the core of SWT will not grow. What is needed now, is a series
of potent widget-components. They don't need to be distributed along with
SWT. They could and probably should be separate projects.

>>>>> It would make sense to wrap all of these constants with set/get
methods, ala
>>>>> JavaBeans.  I realize JavaBeans isn't supported in SWT but having
properties
>>>>> declared via methods would make the users' lives much easier.  Under
the
>>>>> covers, the SWT programmers can still use the SWT constants to avoid
>>>>> breaking existing code.

I personally don't need the SWT developers to add anything. Let's just take
out the bugs, and grow this thing through other projects that build on it
and build in other dimensions. Nothing stops you from creating a project
consisting of purely wrappers that better reflect your own design tastes.