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

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

>>>>> Erik, it's quite true that these things may not be "the way you would
do it" but the time for
>>>>> changing any of these things is long over.  We have API and we must
support it.

That's exactly what I said.

>>>>> I understand the "put the constants in the class" argument.  The
challenge is to find a
>>>>> sensible home for every constant.  Since this design decision is never
changing, you
>>>>> could go and do the work, find the home for every constant but it
would be for fun only.
>>>>> The results would be interesting, would show us how to be better next
time, but we
>>>>> couldn't use them.

I'm not in favour of the "put the constants in the class" argument at this
point in time. As a matter of fact, the point is moot, also in my opinion.

>>>>> I don't really understand the TypedListener scalability problem other
than the obvious,
>>>>> "I hate the case statement and casting, it's ugly".  TypedListener is
really an internal class,
>>>>> used by SWT to map from untyped to typed events.  It is not intended
to be used outside
>>>>> of SWT.

I don't have a problem with the case statement and casting. Or the fact that
it's ugly. My concern is different. It's about the fact that all the events
are numbered, and that these numbers are hardcoded. If sourcebase X adds
events (and therefore numbers) and event Y adds events and therefore another
series of hardcoded numbers, how will you guarantee that they will not be
using the same numbers?

For example, KeyDown=1. If I send a self-defined event with id=1 through the
system, what will happen? Are you sure it won't conflict with KeyDown in any
possible way? In theory it could work, but I haven't tried. Of course,
handleEvent() in my own typed listener will, most likely, get invoked, but I
feel wary of the situation.  Some people will start hardcoding things,
knowing that KeyDown=1. It will get tricky.

>>>>> Can you suggest a better implementation for us?

There is no need for a better implementation that the current one. The
current one displays nice results and is very useable with GCJ. I don't need
extensions, improvements, and so on. Puhlease. The sourcebase is, in my
opinion, finished. Potent widgets that extend SWT are, in my opinion,
separate projects.

(1) Bug fixes in the existing libraries.
(2) new platforms, if possible.
(3) More examples of how to use the framework.

The event numbering could maybe be improved by distributing these event ids
at startup through something like an "EventNumberRegistrar"; so that nobody
would hardcode anything against KeyDown=1.

My current concerns are different at this point in time.

For example, I'm thinking of writing up a brand new EditableTable, starting
all the way from the "Canvas" instead of starting from "Table". I could use
more, and new examples of how use "Canvas", which are simplified to
illustrate one point at a time (unlike the sources themselves, which, by the
nature of things, do a lot of things at a time).

I could, for example, also use a print preview canvas. I don't need it now,
but I will in the nearby future. I need examplets as to how to build it from
"Canvas". Idem for a multicolumn combo.

Nobody needs to write them for me. But I would appreciate many more
examplets that illustrate a particular point. By the way, it is my intention
to contribute these widgets back to the domain. I've got one widget working
fine already; an "EditableTable" starting from "Table", typically for use
with database oriented applications.

Maybe you could set up an area in which people can contribute examplets, and
the widgets they have made; and appoint someone from your team to manage and
animate this area. That would be an idea. Tell me when the area is
accessible, and I will contribute my 800 lines of EditableTable to it.