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

[Oleg Sukhodolsky]

On Tue, Aug 25, 2009 at 6:08 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
> Hi Oleg,
>
> Thank you for the comments.
>
> On 08/25/2009 05:47 PM, Oleg Sukhodolsky wrote:
>>>
>>> public void java.awt.Window.setType(Type type);
>>> public Type java.awt.Window.getType();
>>>
>>> **************************************************
>>
>> - providing a setter for this property you open door for number of
>> questions such as "when this methods can be called" or "when user will
>> see result of the call"
>
> The EWMH specification states that the hint should be set prior to mapping
> the window. I haven't tested it yet, but I guess MS Windows is able to apply
> the style on the fly,
> In both cases we can say that the effect is guaranteed to be applied upon
> subsequent showing the window, or we may even enforce it applying the style
> ONLY upon showing - but I don't think we should. So it doesn't seem to be a
> serious problem.

you will need to specify all possible issues carefully, and, as far as
I remember,
writing such specification is a pain.

>> - adding this property to Windows you create situation when some
>> methods of Window will not work (should not be called) in certain
>> situations, e.g.
>>  setUndecorated(), setWindowFocusableState() etc.
>
> I don't actually see why the methods (or some other) should be prohibited.
> For instance, a toolbar may not have a system title bar but still set the
> needed style in order to employ the toolbar-style focus behavior, etc. Of
> course, we need to pay attention to correctly document that certain calls
> can change the default behavior enforced by a particular style. After all,
> it's going to be user's responsibility, but at least, AFAIK, it's not
> prohibited by the native system.

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

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

Oleg.
> --
> best regards,
> Anthony
>