Re: [albireo-dev] size and border

[Bruno Haible <haible@xxxxxxx>]

Hi Gordon,

> Because the borderless child is created as a Composite and not a 
> SwingControl, I think there may be regressions in our focus handling 
> support. We depend on an override of forceFocus(), for example, to work 
>   around problems with the reliability of focus queries.

You are right that there are interactions between the border support and
potentially all other facets of SwingControl. (Although I would not call it
a "regression", since the use of SWT.BORDER flag was not supported before.)

I checked all uses of 'this' in SwingControl.java, and the only remaining
issues appear to be:
  - the FocusHandler constructor invocation,
  - the forceFocus overide,
  - the listeners added in initKeystrokeManagement().

> Is there any reason the borderless child can't itself be another 
> SwingControl? If not, how would you propose to fix this?

Making the borderless child an instance of SwingControl was my first attempt.
The problem is that we have so many overrides, caches and extra functionality
added to SwingControl that this functionality would be duplicated. This could
be avoided by putting into every override a test

    if (this == borderlessChild)
      /* code to be executed only in the child */

or

    if (this != borderlessChild)
      /* code to be executed only in the parent */

But then the second problem would be the public overridable API of the
SwingControl class. If a user overrides, say, preferredSizeChanged, the
borderlessChild would have to invoke this method on its parent SwingControl -
otherwise the user's override is ignored.

So we had ended up with a situation where it's very hard to understand which
code is executed in the borderlessChild and which code in the parent.

The design I therefore chose is:
  - All public or overridable API is on the outer SwingControl. The
    borderlessChild is not publicly visible.
  - All logic is on the outer SwingControl. The borderlessChild comes into
    play only through the direct effects of SWT_AWT.
  - Only the minimum number of overrides is done on the borderlessChild's
    class. So far it's only getClientArea and forceFocus.

> Also, is there a straightforward rule for determining whether to use 
> "this" vs. the borderlessChild member when implementing code inside 
> SwingControl?

More or less, this is the rule: Only the direct effects of SWT_AWT force us
to use borderlessChild. For all API and high-level overrides, use the
outer SwingControl.

Unfortunately this rule is ambiguous regarding focus... I have the focus
fixes working for the SWT.BORDER case now; I'll clean up and commit these
modifications tomorrow.

Bruno