ANNOUNCE - graphics package
Mon Jan 19 20:42:09 CET 2004
Olivier Lefevre wrote:
> Full concurrency is certainly an interesting experiment
> but is it _needed_?
I don't have a definitive answer to this one, but imagine a real-time
data acquisition application: it will generate a separate stream of
events that must be integrated into the GUI display.
I'm not entirely sure, but I think keeping things fully concurrent is a
bonus for that kind of application.
I suspect that this independent event source thing is the key point.
If you have such event sources, it's likely that only a very limited set
of widgets is interested in them (in the case of data acquisition, the
events may go to a scrolling event log and/or a status display, there's
usually no reason why window frames or text input fields should be
bothered with them).
If you have full concurrency, you can feed these messages directly to
the interested controls. It's actually easy to set up a process that can
accept both GUI messages and data acquisition messages, and Do the Right
Thing with each kind of message.
If you don't have full concurrency, you must feed the independent
messages into the message dispatcher. This means defining a special kind
of message, *and* making sure that the message ultimately is dispatched
to exactly those controls that can make sense of it. That's a horrible
hassle. (Been there, done that. It's really not a pretty sight, and -
worst of all - it's something from the application domain, but to
program it, you need intricate knowledge of the GUI library because you
have to tamper with one of its central mechanisms, namely message dispatch.)
Here's the grain of salt: I don't know the ins and outs of the decision
to drop concurrency in Swing.
One of the things that I suspect is that the Java model of concurrency
is quite heavyweight, which means developers are constantly trying to
invent mechanisms to circumvent it. Which, of course, means that they
are going to introduce bugs in that mechanism, which can easily lead to
the described behaviour.
My other guess is that redrawing wasn't very well-designed in AWT
(witness the constant "things don't redraw properly" posts by newbies on
the awt newsgroups), and it may be that Swing inherited these problems.
(I find it quite strange that redrawing is a difficult task in AWT.
Actually that's one of the few things that are easy in in Windows...
it's been ages since I have been bitten by a bug in this area, and only
if I was handcrafting my own custom controls.)
Currently looking for a new job.
More information about the erlang-questions