[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [albireo-dev] thoughts on API
|
Bruno Haible wrote:
About the API
=============
It's clear that some features will be optional: some users will want them,
some won't. For example:
- Set the Swing look&feel to match the platform one, rather than Metal?
- Enable popup-menus on subcomponents?
- Merge the two event threads?
- Do tricky things with focus events?
- Reflect the explicitly set AWT cursor as an SWT cursor?
A general reason to switch them off is that each such tricky treatment
(of events, or overrides) can have negative effects. For example, I would
not have expected that there are side effects between the popup menus and
the focus subsystem, but there are.
I agree.
There shall be a class that wraps a Swing component in an SWT control.
(Previously called EmbeddedSwingComposite in the SAS contribution or
IlvSwingControl in the ILOG contribution.)
(By the way, your name IlvSwingControl is a better one, and we should
use it, minus the prefix of course)
But there are also global
facilities that can be turned on or off. Should they be available through
static methods in the above mentioned class, or in a separate class with
only static API? I have a slight preference for the latter.
I, too, prefer a separate class, but used as a singleton just like your
focus handler example below.
It would also be nice if some of the global options could be controlled
without changing code. This would be useful to quickly debug whether one
of the facilities is indeed causing a strange side effect - without
having to rebuild.
So maybe there is a Java property associated with each relevant option?
On initialization, if the property is set, its value is used to set the
option's default. Otherwise, the option is initialized to s standard
default value. The application can then programmatically change the
option through the singleton instance of the options class. (i.e. the
code overrides any property setting.) Any subsequent changes to the
property are *not* tracked.
At least some of the options must/should be set before anything else is
done. This will need to be documented.
Our property names should have a common prefix ("org.eclipse.albireo.")
If we were a higher level project, I'd suggest something other than
properties (e.g. Eclipse preferences).
Openness: It's very likely that some applications will need to fine-tune
services provided by Albireo. For example, handle particular types of
events in the AWT thread rather than in the SWT thread. Or, don't forward
particular focus events from the AWT component to the SWT component. This
means, most of the core parts of Albireo should IMO be open - i.e. overridable
and replaceable. I think the good design pattern for this is the singleton
pattern for a non-final class.
I agree. We'll need to think about it carefully though. If we allow
subclassing, then there is a much larger burden to ensure future
compatibility. There's a reason that SWT discourages subclassing of most
widgets.
