[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [albireo-dev] thoughts on how to proceed
|
Bruno,
Very interesting! Some thoughts below.
Bruno Haible wrote:
Hi Gordon,
Some thoughts about testing and its implications.
About the tests
===============
Changes in the mouse event subsystem will inevitably have an effect on
what happens with the focus and with the cursors. There are many similar
dependencies.
Agreed (strongly :-).
...
Therefore, I would find it appropriate to have a set of tests that can
be run to verify the functioning of particular features. These tests are
manual (since that's probably more faithful than any java.awt.Robot like
class).
Sadly, I agree here too. Still, I would like to try for some degree of
automated testing where technically possible. As sincerely as we might
promise to run the manual tests, there will be times when they are not run.
What to do first
================
Mouse events handling should be implemented before focus event handling;
simple key events handling should be implemented before focus event handling;
popup menus should be implemented after focus event handling, IMO.
Yes, this is an area where we should try to walk before we run. By
getting the mouse handling done, we'll have a reasonable platform on
which to add all the other features.
In general, I prefer to start with the harder task (which would be focus
handling in this case) because we'd find out sooner if our plans are
feasible. But, it won't really work in this case, and, besides, we
already know the requirements and implementation challenges well.
If we want to have the same code )mostly) across all platforms, this means
IMO that we have to test the mouse event handling on all platforms before
we can start working on focus event handling. Otherwise, we discover late
that mouse events on, say, MacOS X, work differently, have to rewrite
the mouse event handling, and the focus event handling on Windows gets
easily broken.
Yes, waiting until the end to test on all platforms is a mistake. I have
easy access to Windows (Vista/XP/2000) and Linux, by the way, so I think
we have the platforms well covered.
But first of all, I think, the single-event-thread feature should be
implemented. The reason is that
1) single-event-thread is an important feature: many developers will
not be able to build a _large_ and _reliable_ application if they
have to constantly switch from AWT to SWT thread and back, using
various synchronization mechanisms.
Unfortunately, many developers will not be able to use the single event
thread feature if modal dialogs are not supported. But this is all the
more reason to implement it sooner, so that we have more time to deal
with these issues.
(And, for the record, I don't agree that the large and reliable
applications are not possible for many developers with the multi-event
thread approach. There are a lot of factors to consider, including the
degree of interaction required between AWT and SWT. This largely depends
on the type of components being embedded.).
I think it would be easy to start by creating a very simple SwingControl
class that works (via mouse only) for multi event thread use. Perhaps I
should do that, and then you can add in a basic single thread
implementation, and we could proceed from there? I think it would be
easier to think/talk about design if we have a shared(prototype)
implementation. This is just my opinion, and I'd love to hear
alternatives...
