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

[Anthony Petrov]

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).

--
best regards,
Anthony