<AWT Dev> Thoughts about 6402325 (Swing toolbars vs native toolbars on Windows)

[Oleg Sukhodolsky]

On Tue, Aug 25, 2009 at 6:57 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
> On 08/25/2009 06:32 PM, Oleg Sukhodolsky wrote:
>>
>> you will need to specify all possible issues carefully, and, as far as
>> I remember,
>> writing such specification is a pain.
>
> ...
>>
>> you need to specify correct behavior at least for JCK (but I suspect,
>> that users would like to have good specification too ;)
>>
>> Also "more specification" == "harder to use".
>
> Agreed. OTOH, no or little specification usually results in unsatisfied
> over-optimistic expectations. :)
>
> Regarding technical details, it is obvious that the set of "restricted"
> calls depends on the style in question. So we could specify that the
> behavior of UTILITY windows is undefined if a developer invokes any
> focus-related methods on that window, and then list a few methods of that
> kind to give examples (e.g. setWindowFocusableState()). This seems to be
> quite enough to make both the JCK and the developers happy. We'll review the
> specification proposal on this mailing list in a little while.
>
>
>>>> As possible resolution for the first issue we could use some factory
>>>> methods/classes.
>>>
>>> That looks like a really bad idea to me. Just recall the number of
>>> constructors the JDialog currently has... So I would like to avoid both
>>> adding new parameters to constructors, and creating any factory
>>> methods/classes.
>>
>> It is really abstract question, but factory class is supposed to
>> minimize number of factory methods and ctors ;)
>
> This is no different than specifying that a method may only be invoked when
> the window is hidden (setUndecorated() comes to mind), or has not yet been
> shown - like the pack() that is only meaningful before first showing, etc.
> But adding simple methods creates less syntactic garbage at least, and also
> enables to change some properties on the fly (even if hiding the window is
> required).

>From the other hand adding one more property to Window creates a lot
of possible combinations
you need to consider (e.g. how
always-on-top+unfocusable+undecorated+modal dialog will behave,
and do you really wants to allow such monster to exist ;)
I'm just trying to say that, perhaps, adding new class/interface for
specific toplevel would be
easier to understand (and maintain).  Though I agree that such
approach has its own problems.

Oleg.